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Abstract 


This  Technical  Memo  describes  the  background,  aims,  and  methodology  for  adding  new 
capabilities,  in  the  form  of  new  extensions,  to  the  North  Atlantic  Treaty  Organization  (NATO) 
Ground  Moving  Target  Indication  Format  (GMTIF),  known  by  NATO  as  Standardization 
Agreement  (STANAG)  4607.  These  changes  are  required  to  accommodate  new  sensors, 
processing  techniques,  and  sensor  modes  of  operation,  such  as  will  be  available  from  the 
Synthetic  Aperture  Radar  -  Ground  Moving  Indication  (SAR-GMTI)  mode  onboard 
RADARSAT-2.  Further  additions  are  also  made  to  provide  a  level  of  redundancy  and  flexibility. 
The  RADARSAT-2  GMTI  group  at  DRDC  Ottawa  was  instrumental  in  identifying  and 
developing  these  changes  and  having  them  incoiporated  into  the  GMTIF  in  time  to  support 
RADARSAT-2.  The  resulting  changes,  contained  in  Annex  B,  are  preliminary  and  were  needed 
to  support  data  from  the  GMTI  mode  onboard  RADARSAT-2.  Dissemination  of  GMTI  products 
is  an  important  component  of  the  Department  of  National  Defence’s  (DND)  RADARSAT-2 
GMTI  Technology  Demonstration  Project  (TDP),  which  aims  to  demonstrate  the  utility  of  space- 
home  GMTI  measurements.  RADARSAT-2  will  be  the  first  spaceborne  SAR-GMTI  platform  to 
implement  STANAG  4607.  These  advanced  segment  extensions  will  greatly  enhance  the 
dissemination  capacity  of  GMTI  data  between  various  sensors  and  users.  They  will  continue  to 
evolve  to  further  increase  the  utility  and  ease  of  use  of  GMTIF  data  to  exploitation  systems. 


Resume 


Ce  Memorandum  presente  la  motivation,  les  objectifs,  ainsi  que  la  methodologie  utilisee  pour 
l’addition  de  nouvelles  capacites  au  format  d’indication  de  cibles  terrestres  mobiles  (GMTIF)  de 
l’Organisation  du  Traite  de  l’Atlantique  Nord  (OTAN),  connu  par  l’OTAN  comme  l’accord  de 
normalisation  (STANAG)  4607.  L’ augmentation  du  format  est  requis  afm  d’accommoder  de 
nouveaux  capteurs  ou  modes  d’operation,  ainsi  que  des  nouvelles  techniques  de  traitement  de 
donnees,  tels  que  seront  disponibles  en  provenance  du  mode  d' indication  de  cibles  terrestres 
mobiles  -  Radar  a  Ouverture  Synthetique  (SAR-GMTI)  a  bord  de  RADARSAT-2.  Ces 
changements  foumissent  aussi  aux  utilisateurs  du  format  un  niveau  superieur  de  redondance  et  de 
flexibilite.  Le  groupe  du  projet  RADARSAT-2  GMTI  a  RDDC  Ottawa  a  pris  la  responsabilite 
d’identifier  et  de  developper  les  additions  necessaires  aux  segments  de  base,  ainsi  que  d’avoir  ces 
changements  reconnus  et  incorpores  au  sein  du  GMTIF  en  temps  pour  etre  utilises  en  appui  de 
RADARSAT-2.  Les  modifications  resultantes,  enumerees  dans  l’Annexe  B,  sont  preliminaires. 
Elies  etaient  requises  afm  d’accommoder  les  donnees  en  provenance  du  mode  GMTI  de 
RADARSAT-2.  La  diffusion  de  produits  GMTI  est  une  composante  importante  du  Projet  de 
Demonstration  de  Technologies  (PDT)  RADARSAT-2-GMTI  du  Ministere  de  la  Defense 
Nationale  (MND),  le  but  de  ce  dernier  etant  de  demontrer  l’efficacite  des  mesures  de  cibles 
mobiles  a  partir  de  l’espace.  Le  satellite  RADARSAT-2  sera  la  premiere  plateforme  SAR-GMTI 
spatiale  a  realiser  le  format  STANAG  4607.  Ces  augmentations  aux  segments  de  base  faciliteront 
la  dissemination  de  donnees  GMTI  entre  differents  capteurs  et  utilisateurs.  Elies  continueront  a 
evoluer  afm  d’augmenter  davantage  l’aise  de  traitement  de  donnees  et  l’utilite  de  produits  GMTIF 
aux  systemes  d’exploitation  de  donnees. 
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Executive  summary 


The  Addition  of  Enhanced  Capabilities  to  NATO  GMTIF  STANAG  4607  to  Support 
RADARSAT-2  GMTI  Data 

Beaulne,  P.D.  DRDC  Ottawa  TM  2007-341;  Defence  R&D  Canada  -  Ottawa; 
December  2007. 

Introduction:  STANAG  4607  is  a  binary,  message-oriented  format  for  the  prompt  dissemination 
of  GMTI  data  between  coalition  partners.  However,  as  it  presently  stands,  its  capacity  to  support 
SAR-GMTI  data  collected  from  a  space  platform  such  as  RADARSAT-2  is  limited.  Supporting 
such  data  requires  the  addition  into  the  GMTIF  of  new  capabilities  in  the  form  of  advanced 
extensions  to  existing  GMTIF  segments. 

Results:  The  advanced  segment  extensions  that  have  been  developed  at  the  behest  of  the  DRDC- 
Ottawa  RADARSAT-2  GMTI  team  fully  support  spaceborne  SAR-GMTI  sensors  and  provide 
additional  sensor  and  target  ancillary  data  to  enhance  exploitation  possibilities  of  the  GMTI  data. 
They  will  play  a  critical  role  in  demonstrating  the  use  and  capabilities  of  the  RADARSAT-2 
GMTI  mode  to  the  Canadian  Forces  (CF).  The  manner  in  which  the  additions  have  been 
implemented  preserves  the  backward  compatibility  of  this  new  version  of  STANAG  4607  with 
earlier  ones. 

Significance:  Much  of  the  information  in  this  document  was  used  as  a  baseline  in  the 
development  of  the  advanced  GMTIF  extensions.  The  addition  of  support  for  spaceborne  SAR- 
GMTI  data  provides  an  increased  capacity  to  exploit  such  data,  as  well  as  an  additional 
information  layer,  and  should  result  in  improved  interoperability  of  joint  and  coalition  forces 
using  GMTI  data,  as  has  been  shown  in  various  NATO  interoperability  exercises  using  the  base 
(airborne)  version  of  STANAG  4607.  The  new  capacity  to  support  spaceborne  SAR-GMTI  data 
will  offer  enhanced  support  for  the  warfighter,  especially  in  visualizing  the  battlefield. 

Future  plans:  The  STANAG  4607  segments  and  extensions  described  herein  are  being 
implemented  by  DRDC  Ottawa  to  support  GMTI  data  from  RADARSAT-2.  As  implementation 
and  testing  of  the  extended  STANAG  4607  continue,  both  at  DRDC  and  elsewhere  in  Canada  and 
within  NATO,  there  will  be  a  need  to  correct  errors,  clarify  some  areas  and  add  support  for 
further  sensor  capabilities.  Future  versions  of  the  STANAG,  for  example,  could  contain  features 
such  as  track  data,  MTI  derived  from  motion  imagery,  and  maritime  mode  radar.  To 
accommodate  this  future  growth,  the  GMTI  Custodial  Support  Team,  working  in  conjunction 
with  the  STANAG  4607  custodian,  will  be  responsible  for  continued  maintenance  and 
configuration  management  over  the  lifetime  of  the  STANAG. 
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Introduction:  Le  STANAG  4607  est  un  format  binaire,  style-message,  pour  la  diffusion  de 
donnees  GMTI  entre  partenaires  dans  une  coalition.  Cependant,  le  GMTIF  tel  qu’il  existe 
presentement  possede  une  capacite  de  soutien  limitee  pour  des  donnees  SAR-GMTI  en 
provenance  d’une  plateforme  spatiale  telle  que  RADARSAT-2.  Le  soutien  de  telles  donnees 
necessite  T  addition  au  sein  du  GMTIF  de  nouvelles  capacites,  celles-ci  prenant  la  forme 
d’ augmentations  avancees  aux  segments  de  base  du  GMTIF. 

Resultats:  Les  augmentations  avancees  ont  ete  developpees  suite  aux  interventions  du  groupe 
RADARSAT-2  GMTI  de  RDDC  Ottawa.  Elies  permettent  le  soutien  complet  de  capteurs  SAR- 
GMTI  spatiaux  et  foumissent  de  T information  ancillaire,  ce  qui  permet  d'augmenter  les 
possibilites  d' exploitation  des  donnees  GMTI.  Ces  augmentations  auront  un  role  essentiel  dans  la 
demonstration  des  capacites  du  mode  GMTI  de  RADARSAT-2  aux  Forces  Canadiennes  (FC). 
La  fa9on  dont  ces  modifications  ont  ete  effectuees  preserve  aussi  l’arriere-compatibilite  de  cette 
nouvelle  version  du  STANAG  4607  avec  les  versions  precedentes. 

Importance:  La  majorite  du  contenu  de  ce  document  a  servi  comme  ligne  de  base  pour  le 
developpement  des  augmentations  GMTIF  avancees.  L’addition  du  soutien  de  donnees  SAR- 
GMTI  spatiales  foumi  une  capacite  augmentee  d’ exploitation  de  telles  donnees,  ainsi  qu’un  plan 
d’information  additionnel.  Ceci  devrait  ameliorer  le  niveau  d’interoperabilite  entre  les  forces  dans 
une  coalition,  ce  qui  a  ete  demontre  dans  plusieurs  exercices  d’interoperabilite  de  l’OTAN  avec  le 
format  GMTIF  (aerien)  de  base.  Cette  nouvelle  capacite  offfira  aux  guerriers  un  soutien  ameliore 
pour  la  visualisation  du  champ  de  bataille. 

Perspectives:  Les  segments  (aeriens)  de  base  du  STANAG  4607,  ainsi  que  les  augmentations 
avancees  presentees  dans  ce  memorandum  seront  realises  par  RDDC  Ottawa  en  soutien  de 
donnees  SAR-GMTI  de  RADARSAT-2.  Comme  la  realisation  et  la  verification  du  nouveau 
STANAG  4607  continuent  a  RDDC,  au  Canada  et  au  sein  de  l’OTAN,  il  sera  necessaire  de 
corriger  des  erreurs,  de  clarifier  certains  concepts  et  d’ajouter  du  soutien  pour  des  capteurs  plus 
avances.  Les  versions  futures  du  STANAG  pourraient  contenir,  par  exemple,  un  segment  de 
poursuite  de  cibles,  un  segment  de  donnees  GMTI  derivees  d’imagerie  video  ou  un  segment  pour 
caracteriser  les  cibles  mobiles  maritimes.  Afm  d’accommoder  ces  futures  modifications,  l’equipe 
de  support  technique  du  format  4607,  en  collaboration  avec  le  gardien  responsable  pour  le  format, 
seront  responsables  pour  Tentretien  et  pour  la  gestion  de  configuration  du  format  pendant  sa 
duree  de  vie. 
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1  Introduction  and  Background 


STANAG  4607,  the  NATO  Ground  Moving  Target  Indicator  Format  (GMTIF),  is  one  of  several 
Intelligence,  Surveillance,  and  Reconnaissance  (ISR)  standardization  agreements  (STANAGs) 
called  out  under  the  NATO  Intelligence,  Surveillance,  and  Reconnaissance  Interoperability 
Architecture  (NIIA)  [1],  This  NATO  effort  evolved  from  of  the  Common  Ground  Moving  Data 
Indicator  (CGMTI)  Format,  which  had  previously  been  developed  from  the  ground  up  as  a 
“universal”  standard  to  meet  the  requirements  of  legacy  and  future  U.S.  radar  systems  for  GMTI 
products. 

The  basic  method  for  developing  the  STANAG  was  to  survey  applicable  legacy  standards  (such 
as  the  NATO  Exploitation  Format  (NATO-EX),  the  National  Imagery  Transmission  Format 
(NITF),  and  others);  determine  which  data  elements  (including  data  fields,  parameters,  and 
values)  were  required;  and  develop  a  clear,  easy-to-implement  standard  based  on  those  elements. 
The  standard  should  also  be  capable  of  growth  and  expansion  to  accommodate  new  requirements 
and  sensor  platforms,  while  maintaining  backward  and  forward  compatibility  between  editions  or 
versions. 

The  first  base  editions  of  the  STANAG  resulted  from  the  ‘fusion’  of  information  available  from 
various  existing  (airborne)  GMTI  sensor  platforms.  As  such,  they  do  not  readily  support  the  use 
of  spaceborne  platforms  or  multichannel  Synthetic  Aperture  Radar  (SAR)  GMTI  sensors,  such  as 
that  carried  onboard  RADARSAT-2.  The  base  editions  also  lack  some  simple  ancillary 
information  regarding  properties  of  detected  targets  and  their  clutter  environment  and  do  not 
readily  support  sensor-centred  coordinate  systems  for  reporting  target  location.  The  addition  of 
such  quantities  to  the  GMTIF  would  allow  it  to  support  GMTI  data  from  RADARSAT-2  (or, 
more  generally,  from  any  space-borne  platform  or  multichannel  SAR  GMTI  sensor),  greatly 
enhancing  the  possibilities  for  exploitation  of  the  GMTI  data  and  permitting  the  Canadian  Forces 
(CF)  to  be  interoperable  in  a  coalition  environment. 

As  the  RADARSAT-2  GMTI  Technology  Demonstration  Project  (TDP)  [2]  aims  to  demonstrate 
the  capabilities  and  the  utility  (including  bi  or  multi  lateral  interoperability  with  NATO/coalition 
partners)  of  spaceborne  SAR-GMTI,  a  suitable  format  for  the  exchange  of  the  derived  GMTI  data 
is  needed.  Since  STANAG  4607  is  expandable,  it  was  decided  that  it  should  be  modified  to 
support  spaceborne  SAR-GMTI  platforms,  as  well  as  sensor  coordinate  and  additional  ancillary 
data  reports.  The  DRDC  RADARSAT-2  GMTI  project  team  was  the  main  driver  pushing  for 
these  modifications,  through  the  author  of  this  note,  who  became  a  member  of  the  NATO  4607 
Technical  Support  Team  responsible  for  changes  to  the  GMTIF 

In  the  first  three  sections,  this  document  describes  the  present  edition  of  STANAG  4607,  the 
philosophy  behind  its  development  and  use  and  its  present  shortcomings.  The  required  additional 
capabilities  in  support  of  RADARSAT-2,  and  their  rationale,  are  described  in  section  4  and  the 
extensions  themselves  are  described  Annex  B.  They  represent  the  Canadian  (through  DRDC 
Ottawa)  contribution  to  the  evolution  of  GMTIF  STANAG  4607. 
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2  The  Aim  and  Philosophy  of  STANAG  4607 


The  aim  of  the  NATO  GMTIF,  STANAG  4607,  is  to  promote  interoperability  for  the  exchange  of 
ground  moving  target  indicator  radar  data  among  North  Atlantic  Treaty  Organisation  (NATO) 
Intelligence,  Surveillance,  and  Reconnaissance  (ISR)  Systems,  via  the  prompt  dissemination  of 
MTI  data.  The  STANAG  defines  a  standard  for  the  data  content  and  format  for  the  products  of 
ground  moving  target  indicator  radar  systems,  regardless  of  their  level  of  sophistication. 

The  GMTI  Format  (GMTIF)  originated  as  an  initiative  to  develop  a  common  format  to  support 
the  dissemination  of  ground  MTI  data  from  US  sensor  platforms  [3].  It  was  developed  by  a 
working  group  originally  consisting  of  representatives  from  US  Government  and  Industry,  which 
later  grew  to  include  Canada  and  the  UK.  Ultimately,  NATO  Air  Group  IV  (AG  IV)  (now  the 
Joint  ISR  Capabilities  Group,  JISRCG)  recognized  the  need  to  define  a  standard  for  GMTI  data 
and  the  NATO  GMTI  Technical  Support  Team  (TST)  was  created.  The  GMTI  TST  was  assigned 
under  AG  IV’s  Intelligence,  Surveillance,  and  Reconnaissance  Integration  Working  Group 
(ISRIWG)  and,  with  the  promulgation  of  the  first  editions  of  STANAG  4607,  is  now  designated 
as  the  Custodial  Support  Team  (CST).  The  CST  is  responsible  for  any  additions  or  modifications 
necessary  in  the  future  evolution  of  the  STANAG. 


STANAG  4607  is  primarily  intended  for  data  exchange  between  GMTI  radar  systems  and  their 
exploitation  systems  and  to  facilitate  transmission,  fusion,  and  display  of  that  data.  It  provides  a 
structured  approach  for  various  types  of  users  (for  example,  low  or  high  bandwidth)  and  an 
incremental  fielding  approach,  depending  on  the  user’s  particular  data  requirements.  It  can  be 
used  either  as  a  standalone,  embedded  into  other  STANAGs,  such  as  the  NATO  Secondary 
Imagery  Format  (NSIF,  STANAG  4545)  or  the  NATO  Primary  Imagery  Format  (STANAG 
7023),  used  with  the  NATO  Standard  Library  Interface  (NSILI,  STANAG  4559),  or  disseminated 
in  an  XML  version. 


The  format  is  scalable  to  all  levels  of  capability.  Small-scale  systems  can  use  only  those  elements 
of  the  format  required  to  transmit  their  data,  while  more  robust  systems  can  use  more  aspects  of 
the  format  to  encode  all  available  information.  For  example,  a  user  responsible  for  target  attack 
would  require  significantly  more  information  for  a  relatively  small  number  of  movers  or  targets, 
in  comparison  to  a  user  who  is  interested  only  in  situational  awareness  or  knowing  the  general 
location  of  many  potential  movers. 

To  accomplish  this  scalability,  the  format  uses  two  technical  approaches.  First,  the  format  is 
divided  into  segments,  with  no  predefined  order  or  sequence  other  than  the  requirement  to  preface 
data  segments  with  appropriate  header  segments,  as  defined  in  the  standard.  Each  system  using 
the  standard  is  free  to  select  the  particular  segments  it  requires  for  the  data  produced.  Secondly, 
not  all  of  the  data  fields  within  the  segments  need  be  sent,  but  may  be  transmitted  if  they  are 
available  and  if  they  provide  added  value  or  utility  and  are  not  constrained  by  communications  or 
operational  considerations.  With  these  approaches,  each  segment  can  be  tailored  to  the  data 
format  requirements  of  the  particular  system. 
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Figure  1  illustrates  a  notional  diagram  for  the  transmission  of  GMTI  data  from  the  Sensor  System 
to  the  Exploitation  System.  It  shows  the  general  relationships  between  Raw  Data,  GMTI  Data, 
and  the  points  at  which  the  GMTI  Format  could  be  applied.  Note  that  the  additional  processing,  if 
required,  could  be  accomplished  on  the  airbome/spacebome  platform  or  within  the  corresponding 
ground  station,  depending  on  the  system.  For  example,  airborne  platforms  with  exploitation 
capabilities  can  either  transmit  the  GMTI  data  directly  to  its  ground  station  or  can  exploit  it 
directly  on  the  platform.  Note  that  STANAG  4607  (with  the  possible  use  of  other  NATO  imagery 
STANAGS)  can  be  used  to  disseminate  data  at  any  processing/exploitation  stage  shown  in  Figure 
1. 


Figure  1-  GMTI  Data  Flow  Diagram  (from  [3]) 


The  GMTIF  format  is  also  designed  to  evolve,  since  it  includes  the  methodology  for  adding  new 
capabilities,  in  the  form  of  new  extensions,  to  STANAG  4607.  These  changes  will  be  required  to 
accommodate  new  sensors,  processing  techniques,  and  sensor  modes  of  operation.  The 
methodology  specifies  that  any  changes  to  the  STANAG  must  maintain  forward  and  backward 
compatibility  between  editions  or  versions.  Forward  compatibility  means  that  new  systems  should 
be  designed  such  that  they  can  handle  earlier  versions  of  the  STANAG,  while  backward 
compatibility  means  that  older  systems  should  be  able  to  handle  later  versions  of  the  STANAG  by 
ignoring  certain  segments  or  fields.  This  is  a  multi-step  process,  requiring  proposals  for  new 
extensions  from  the  users  and  approval  of  those  extensions  by  the  STANAG  4607  CST  and 
Custodian  before  they  can  be  added  to  the  STANAG. 

Note  that  the  GMTI  Format  is  not  tailored  to  any  specific  communications  system. 
Communications  systems  requirements  must  be  tailored  to  each  system  on  a  case-by-case  basis. 
Some  key  parameters  to  be  considered  are  as  follows: 
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•  Robustness  of  the  communications  link  (e.g.,  level  of  error  protection  and  correction, 
resistance  to  jamming,  etc.); 

•  Bandwidth  requirements  (e.g.,  using  the  GMTI  Format  direct,  using  the  GMTI  Format 
embedded  in  STANAG  4545  or  7023,  etc.); 

•  Communications  link  restrictions  (e.g.,  packet  size  limitations  when  using  UDP,  etc.); 

•  Link  margins  (e.g.,  transmitter  power,  receiver  sensitivities,  link  losses,  co-channel 
interference,  etc.);  and 

•  Communications  latencies  (e.g.,  processing  time  during  transmission  and  reception, 
satellite  link  delays,  etc.). 

Note  also  that  conformance  with  the  NATO  GMTIF  does  not  in  itself  provide  complete 
interoperability,  since  it  defines  only  one  presentation  layer.  However,  STANAG  4607  does 
provide  data  that  can  be  interpreted  by  any  compliant  ground  system. 
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3  The  Structure  of  STANAG  4607 


The  GMTIF  is  a  binary,  message-oriented  format  that  is  structured  as  a  set  of  Message  Segments, 
with  each  Message  Segment  designed  to  carry  specific  types  of  information.  STANAG  4607 
transmission  is  accomplished  by  means  of  packets,  where  each  packet  consists  of  a  Packet  Header 
and  a  number  of  Message  Segments  containing  GMTI  data  pertinent  to  one  radar  job.  Only  those 
segments  applicable  to  RADARS AT-2  SAR-GMTI  data  are  discussed  in  the  following. 


Each  segment  carries  a  particular  type  of  information,  and  any  of  these  segments  can  be  selected 
as  required  by  mission  requirements  and  transmitted  within  a  packet  with  other  segments  in  any 
desired  order.  If  the  amount  of  data  exceeds  the  size  limit  of  a  GMTIF  packet  or  if  it  is  necessary 
to  send  the  data  in  support  of  time-critical  missions,  the  format  allows  a  portion  of  the  data  to  be 
sent  in  one  GMTIF  packet  and  the  remainder  of  the  data  to  be  sent  in  subsequent  GMTIF  packets 


A  Segment  Header,  which  defines  the  type  of  message  and  the  length  (in  bytes)  of  the  following 
segment,  precedes  each  Message  Segment.  Each  Message  Segment  needed  by  RADARSAT-2  is 
defined  in  Annex  A  of  this  document.  These  include  the  Mission,  Job  Definition,  Platform 
Location,  and  Dwell  segments  (which  may  include  associated  target  reports).  The  present  version 
of  the  full  STANAG  also  contains  other  segments,  which  are  not  needed  for  RADARSAT-2 
GMTI  data.  As  well,  placeholders  exist  for  Range-Doppler,  Group,  Attached,  and  System- 
Specific  Segments,  but  these  are  not  implemented  in  the  present  version  of  the  standard. 


GMTIF  information  is  transmitted  in  a  message-oriented  manner,  with  the  message  lengths 
defined  by  the  Segment  Headers.  There  is  no  provision  or  need  for  Start-  or  End-of  Message 
characters  to  be  transmitted.  Multiple  message  segments  of  any  type  may  be  sent  within  the  same 
packet.  Figure  2  illustrates  the  general  structure  of  the  GMTIF  data  packet,  showing 
representative  message  segments.  The  structure  is  constrained  by  the  packet  assembly  rules  for 
each  segment  type,  as  defined  in  Parts  2  and  3  of  STANAG  4607  [4].  Note  that  the  figure 
illustrates  a  typical  GMTI  packet  structure  and  is  not  to  be  construed  as  representing  all  possible 
combinations  of  segments  within  a  packet. 
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Packet  No.  n 


Packet  No.  n+1 


Figure  2  -  Notional  GMTI  Format  Structure  (from  [4]) 


The  data  format  described  herein  allows  for  loss  of  packets  but  assumes  that  the  packets  received 
are  error-free.  It  does  not  specify  error  detection/correction,  encryption,  or  the  physical 
transmission  of  the  data.  These  functions  must  be  accomplished  by  the  lower  layers  of  the 
communications  media  that  transmit  the  data. 

The  STANAG  4607  Packet  Header  is  sent  at  the  beginning  of  each  packet.  It  provides  basic 
information  concerning  the  platform,  the  job,  the  mission,  nationality,  security,  and  the  length  of 
the  packet.  The  Segment  Header  is  sent  at  the  beginning  of  each  segment  transmitted  within  a 
packet  and  specifies  the  type  and  size  of  the  segment  that  follows. 


The  Mission  Segment  provides  basic  information  concerning  the  mission,  including  the  mission 
plan,  the  flight  plan,  the  platform  type  and  configuration,  and  the  reference  time  for  the  mission. 
Although  the  Mission  Segment  is  specified  to  be  sent  at  least  once  every  two  minutes,  it  is 
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preferable  that  it  be  sent  more  often  (e.g.,  every  thirty  seconds),  and  preferably  within  each 
STANAG  4607  packet. 


The  Job  Definition  Segment  provides  information  pertaining  to  the  radar  job  performed  by  the 
sensor,  including  information  pertaining  to  the  geolocation  model  used  in  the  sensor 
measurements. 


The  Platform  Location  Segment  provides  the  means  for  the  platform  to  transmit  its  location 
during  periods  when  it  is  not  collecting  data,  such  as  enroute  to  an  orbit  location  or  during  a  turn. 
It  will  not  be  routinely  used  for  spacebome  platforms  since  their  orbits  are  deterministic. 


The  Dwell  Segment  is  sent  for  each  dwell  of  the  radar  beam.  It  provides  information  related  to 
dwells  and  revisits,  the  sensor  location,  the  coverage  area,  the  time  of  the  dwell,  sensor 
orientation,  and  sensor  parameters.  It  includes  Target  Reports  for  any  GMTI  detections  observed 
within  that  dwell  and  is  sent  even  if  no  targets  are  detected. 


A  description  of  the  above  base  (airborne)  segments  and  the  information  they  contain  is 
reproduced  in  ANNEX  A.  However,  these  are  not  sufficient  to  support  spacebome  SAR-GMTI 
data.  The  shortcomings  of  the  base  segments  and  the  extensions  developed  to  overcome  them  are 
described  in  the  following  section.  More  complete  and  detailed  information  on  the  philosophy, 
development,  content  and  implementation  of  the  base  (airborne)  GMTIF  can  be  found  in  the  lull 
edition  of  the  STANAG  [4]  and  in  the  accompanying  implementation  guide  [5]. 
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4  The  addition  of  new  capabilities 


As  previously  mentioned  in  Section  1,  STANAG  4607  was  initially  developed  from  an  overview 
of  GMTI  formats  used  in  existing  platforms.  Since  these  platforms  are  airborne  and  carry  ‘classic’ 
MTI  sensors  (which  only  measure  target  line  of  sight  (LOS)  velocity),  the  initial  versions  of 
STANAG  4607  cannot  readily  support  data  from  either  a  spacebome  platform  or  a  SAR-GMTI 
sensor.  Therefore,  extensions  to  the  base  segments  were  developed  to  enhance  GMTIF 
capabilities.  This  was  done  in  accordance  with  the  philosophy  described  in  section  2  (achieving 
forward  and  backward  compatibility  while  maintaining  the  STANAG  structure  was  particularly 
important).  The  structure  of  the  data  fields  for  the  proposed  new  extensions  conforms  to  the  data 
and  packet  structure  defined  in  the  initial  (airborne)  versions  of  STANAG  4607  and  discussed  in 
the  previous  section.  The  proposed  new  extensions  will  be  used  in  conjunction  with  the  existing 
Packet  and  Segment  Headers  and  set  of  Segments  in  that  document. 

The  following  subsections  describe  the  present  shortcomings  of  the  STANAG,  the  additions 
necessary  to  support  spacebome  SAR-GMTI  data  and  the  enhanced  exploitation  possibilities 
offered,  as  well  as  the  rationale  behind  the  content  of  the  extensions.  A  full  description  of  the 
advanced  segment  extensions  and  their  content  is  provided  in  Annex  B.  The  proposed  new 
extensions  will  be  used  in  conjunction  with  the  existing  packet  and  segment  headers  and  with  the 
set  of  segments  listed  in  Annex  A.  These  two  annexes  present  the  segments  and  extensions  which 
will  be  supported  by  RADARSAT-2:  they  are  a  subset  of  the  segments  forming  the  full  GMTIF. 

4.1  SAR  dwell  definition  and  sensor-centred  coordinates 

Radar  systems  process  radar  transmissions  and  returns  in  time  intervals.  The  intervals  are  known 
by  various  names  depending  on  the  radar  specialty,  e.g.  dwells,  arrays,  scans,  coherent  processing 
intervals,  etc.  The  dwell  segment  as  defined  in  the  base  GMTIF  does  not  necessarily  have  a  one- 
to-one  relationship  to  this  radar  dwell.  The  4607  Dwell  Segment  allows  a  sensor  to  report  on  a 
grouping  of  zero  or  more  target  reports  for  which  the  sensor  provides  a  single  time,  sensor 
position,  reference  position,  with  simple  estimates  for  the  observed  area  at  the  reported  time.  All 
of  the  target  reports  within  a  dwell  segment  are  valid  for  the  same  (slow)  time,  which  is  to  say  the 
reported  dwell  time. 

The  ‘classical  MTI’  concept  of  a  dwell  has  it  containing  all  targets  detected  in  the  instantaneous 
beam  footprint.  The  targets  appear  at  different  ranges,  but  the  ability  to  localize  them  in  the  cross 
range  direction  is  limited  to  the  size  of  the  beam  footprint  on  the  ground.  This  presents  problems 
for  radar  systems  such  as  a  side-looking  SAR,  where  the  radar  returns  are  coherently  processed  in 
slow  time  to  improve  the  resolution  in  the  cross-range  direction.  This  cross-range  ‘direction’  can 
be  the  angle  of  arrival  (AOA)  of  the  return,  for  example,  or,  in  the  case  of  a  SAR,  the  along-track 
azimuth  position. 

In  a  SAR,  the  azimuth  position  is  obtained  by  coherent  processing  of  a  target’s  radar  returns  over 
an  interval  known  as  a  Coherent  Processing  Interval  (CPI).  For  a  SAR,  the  CPI  is  the  entire  time 
said  target  was  within  the  physical  beam  footprint  of  the  radar.  This  is  also  known  as  synthesizing 
an  aperture,  the  length  of  which  is  just  the  extent  of  the  along-track  beam  footprint  width  [6].  The 
coherent  processing  positions  the  target  in  azimuth  at  the  along-track  location  where  the  target 
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was  broadside  to  the  sensor  (neglecting  beam  squint).  Therefore,  a  SAR  can  localize  a  target  in 
the  cross  range  (azimuth)  direction  to  a  much  greater  precision  than  the  synthetic  aperture  (beam 
footprint)  length. 

The  present  GMTIF  structure,  where  all  target  reports  within  a  dwell  segment  are  referenced  to 
the  same  time,  complicates  the  reporting  of  SAR-GMTI  target  positions.  One  solution  is  to  define 
a  single  dwell  segment  for  each  target,  but  this  would  involve  a  significant  amount  of  information 
duplication. 

The  solution  chosen  for  reporting  RADARS AT-2  SAR-GMTI  data  is  to  define  a  ‘dwell’  as  a 
subset  of  the  coherently  processed  SAR  image  and  ‘pretend’  that  all  targets  detected  within  that 
image  subset  were  observed  at  the  dwell  time  reported  in  the  dwell  segment.  This  is  shown 
conceptually  in  Figure  3.  Radar  returns  are  coherently  processed  over  CPI’s  to  compress  targets 
in  azimuth.  Azimuth  subsets  (groups  of  CPI’s)  are  assembled  into  dwells.  Revisits  are  not 
applicable  to  RADARSAT-2. 

The  azimuth  partitioning  of  the  processed  SAR  image  is  done  on  the  basis  of  detected  targets.  A 
dwell  segment  can  contain  at  most  65535  target  reports,  so  dwell  segments  are  limited  to 
processed  azimuth  subsets  of  less  than  this  number.  However,  the  proper  reporting  of  along  track 
target  positions  within  the  dwell  requires  modification  of  the  base  (airborne)  target  reports. 


Revisits 


Note:  The  radar  data  structure  shown  s  illustrates  only  and 
does  not  reflect  the  design  of  any  particular  system. 


Figure  3  -  Notional  Radar  Dwell  Structure  (from  [4]) 


It  was  therefore  decided  that  the  target  report  extensions  should  provide  a  field  to  specify  a 
target’s  cross  range  position  (in  linear  or  angular  units,  depending  on  the  type  of  MTI  radar).  This 
modification  also  overcomes  another  deficiency  in  the  base  STANAG.  The  granularity  of  the 
dwell  time  field  is  insufficient  to  accommodate  a  SAR  operating  at  a  pulse  repetition  frequency 
(PRF)  greater  than  1  kHz. 
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The  cross-range  position  in  the  target  report  extension  is  specified  in  sensor  centred  coordinates 
using  angles  from  the  sensor  to  the  target,  or  in  the  case  of  SAR,  an  along  track  azimuth  position. 
The  azimuth  position  is  reported  not  as  a  linear  distance,  but  as  a  slow  time  (the  pulse 
transmission  time).  This  slow  time  is  referenced  to  the  dwell  time,  has  a  granularity  of  10 
nanoseconds  and  can  be  positive  or  negative  (since  the  dwell  time  is  at  the  centre  of  the  dwell). 
The  absolute  time  at  which  the  target  is  detected  (dwell  time  +  target  slow  time)  specifies  where 
on  orbit  the  platform  was  located  when  it  was  broadside  to  the  target.  This  absolute  time,  along 
with  the  platform  velocity  provided  in  the  dwell  segment,  allow  for  the  calculation  of  an  azimuth 
distance.  See  section  B.  1  of  Annex  B  for  more  details  on  the  target  azimuth  slow  time,  as  well  as 
on  the  angular  cross-range  specifications. 

The  addition  of  a  sensor-centred  cross  range  measurement  to  the  target  report  extension  allows 
greater  flexibility  in  the  definition  of  dwell  segments.  However,  the  slow  time  does  not 
completely  specify  the  target  position  in  sensor  space.  This  also  requires  the  slant  range  from 
sensor  to  target  at  the  reported  (azimuth)  slow  time.  Hence,  the  measured  target  slant-range  was 
also  included  in  the  target  report  extension  (see  section  B.l  in  Annex  B)  in  order  to  provide  the 
maximum  utility  and  flexibility  in  reporting  target  coordinates. 

The  addition  of  sensor-centred  target  coordinate  reports,  in  addition  to  providing  more  flexibility 
for  platforms  (targets  can  be  reported  in  geographic  coordinates,  sensor  coordinates,  or  both), 
greatly  enhances  the  exploitation  possibilities  of  the  data.  Knowledge  of  platform  position  or 
antenna  pointing,  along  with  the  sensor  measurements  and  an  earth  model,  permit  the  target’s 
geographic  coordinates  to  be  calculated  [7].  This  geolocation  process  can  offer  enhanced 
exploitation  properties. 

In  the  base  GMTIF,  exploitation  stations  must  rely  on  the  target  geographic  coordinates  as 
provided  by  the  platform  or  its  ground  station,  since  sensor  coordinates  are  not  available. 
Information  provided  on  the  platform  position  and  orientation  is  useful  for  creating  area  masks 
and  the  like,  but  provides  little  additional  exploitation  capacity.  However,  when  combined  with 
sensor-centred  target  measurements,  the  enhanced  (see  section  4.2)  platform  information  can  be 
used  to  perform  target  geolocation.  This  enables  an  exploitation  to  recalculate  a  more  accurate 
geographic  target  positions  based  on  better  maps,  elevation  or  geoid  models  or  the  area  than  may 
be  available  to  the  sensors  of  their  groundstations. 

Note  that  reporting  sensor-centred  coordinates  provides  some  redundancy,  which  can  be  useful  in 
the  event  of  packet  loss.  It  also  allows  the  GMTIF  to  be  used  by  a  wider  range  of  GMTI  sensors. 
Sensors  or  groundstations  with  limited  or  no  exploitation  capability  can  simply  report  their 
measurements  and  leave  the  geolocation  to  be  performed  further  down  the  chain.  An  exploitation 
station  may  also  want  to  recalculate  the  positions  of  targets  from  various  sensor  platforms 
according  to  its  own  algorithms  to  ensure  consistency  of  target  reports  in  a  Common  Operating 
Picture  (COP). 

4.2  Coordinate  systems  for  spaceborne  platforms 


In  the  base  GMTIF,  sensor  and  (airborne)  platform  positions  are  measured  in  a  geodetic  system: 
by  longitude  in  degrees  from  the  Greenwich  Meridian  (positive  East);  by  geodetic  latitude  as  the 
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planar  angle  formed  between  the  perpendicular  to  the  reference  ellipsoid  for  the  specified  earth 
model  (the  World  Geodetic  System  of  1984  (WGS-84)  and  the  equatorial  plane  (positive  North); 
and  by  height  in  metres  either  from  the  reference  ellipsoid  (or  from  mean  sea  level  if  a  geoid 
model  is  being  used)  to  the  point  of  interest. 

This  specification  works  well  for  airborne  platforms  but  not  for  spacebome  ones.  Orbiting 
platform  position  coordinates  are  naturally  expressed,  to  a  high  degree  of  accuracy,  in  an  Earth- 
Centred  Cartesian  coordinate  system,  where  the  z-axis  is  the  earth  polar  axis  and  the  xy  plane  is 
the  equatorial  plane  [7].  Such  a  Cartesian  position  can  be  transformed  to  a  geodetic  system. 
However,  the  cost  is  a  loss  in  the  accuracy  of  the  position  specification  and  its  dependence  on  the 
particular  ellipsoid  and/or  geoid  models  used  in  the  transformation.  In  addition,  the  geodetic 
height  field  in  the  base  GMTIF  Dwell  segment  is  too  small  to  report  the  full  range  of  possible 
satellite  altitudes.  It  was  therefore  decided  that  the  advanced  dwell  segment  extension  should 
contain  fields  specifying  the  satellite  position  to  the  nearest  millimetre  in  an  Earth-centred 
Cartesian  system.  More  details  on  these  additions  can  be  found  in  sections  B.l  and  B.3  of  Annex 
B. 

The  base  GMTIF  also  defines  a  platform  orientation  system  at  the  platform  location.  The  platform 
orientation  is  expressed  in  terms  of  Heading  from  true  north  (or  Yaw),  Pitch,  and  Roll  as  a  series 
of  rotations  about  the  Yaw  Axis,  Pitch  Axis,  and  Roll  Axis,  respectively,  as  shown  in  Figure 
A.5. 1 .  Section  A.5  of  Annex  A  more  fully  describes  the  orientation  specification  for  an  airborne 
platform. 

Again  this  attitude  specification  is  sufficient  to  describe  the  orientation  of  an  airborne  platform, 
but  fails  for  one  in  space.  A  satellite  on  orbit  follows  a  specified  path  in  inertial  space,  but  the 
projection  of  its  track  onto  the  ground  follows  a  more  complicated  path  due  to  the  rotation  of  the 
earth  beneath  the  satellite.  As  such,  the  ground  track  heading  from  true  north  is  constantly 
changing. 

It  was  therefore  decided  that  the  advanced  dwell  extension  should  support  the  specification  of 
platform  attitude  in  a  standard  spacecraft-centred  coordinate  system  [8]  where  the  yaw  axis  is 
along  the  radial  position  vector  from  earth  centre  to  the  platform,  the  pitch  axis  is  along  the 
angular  momentum  vector  (i.e.  normal  to  the  plane  formed  by  the  platform  position  and  velocity 
vectors)  and  the  roll  axis  completes  a  right-handed  triad.  This  is  illustrated  in  Figure  4. 
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Yaw  Axis 
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Figure  4  -  Illustration  of  attitude  specification  axes  for  a  spaceborne  platform  .  The  green  position 
vector  relates  the  platform  and  sensor  positions,  (from  [4]). 


The  relationship  between  the  Platform  Position  and  the  sensor  position  is  expressed  as  the  Sensor 
Position  Vector.  This  is  a  vector  (shown  in  green  in  Figure  4)  which  defines  an  offset  from  the 
Platform  centre  of  gravity  to  the  phase  centre  of  the  sensor.  In  the  case  of  an  Electronically 
Steerable  Antenna  (ESA),  the  Sensor  Position  Vector  can  refer  to  any  phase  centre  on  the  antenna, 
and  can  vary  from  dwell  to  dwell.  It  was  decided  that  the  specification  of  this  offset  was  necessary 
for  applications  requiring  a  high  degree  of  precision. 


The  addition  of  these  coordinate  systems  in  the  advanced  extensions  to  the  GMTIF  allows  for  the 
complete  specification  of  platform  and  sensor  positions,  as  well  as  antenna  pointing  information, 
to  as  high  a  degree  of  accuracy  as  can  be  provided  by  the  platform  in  question. 

4.3  Additional  target  characterization  and  error  estimates 

This  section  discusses  additional  data  related  to  target,  sensor  and  data  processing  properties. 
Most  of  the  quantities  listed  below  are  optional  and  need  only  be  transmitted  if  platforms  can  or 
wish  to  provide  the  data.  It  was  decided  that  these  quantities  should  be  added  to  the  base  GMTIF 
in  order  to  fully  support  spaceborne  SAR-GMTI  sensors  and  to  provide  additional  sensor  and 
target  ancillary  data,  as  well  as  error  estimates,  to  enhance  exploitation  possibilities.  A  short 
explanation  of  the  additional  data  quantities  is  provided  below. 
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•  Target  velocity:  The  base  (airborne)  GMTIF  provides  a  single  field  to  report  the  target 
radial  (line  of  sight)  velocity.  However,  certain  MTI  sensors  can  measure  more  than  the 
radial  velocity.  RADARSAT-2  will  be  able  to  measure  radial  velocity,  but  will  also  be 
able  to  resolve  two  velocity  components  for  ground  moving  targets;  one  in  the  along 
track  (azimuth)  direction  and  the  other  in  the  cross-track  (ground  range)  direction.  These 
components  can  also  be  expressed  as  a  target  speed  and  heading.  The  addition  of  these 
quantities  to  the  extended  target  reports  (see  section  B.l  of  Annex  B)  allows  more 
accurate  reporting  of  the  target  velocity  vector  in  the  format  (2  components  or  speed  and 
heading)  most  appropriate  to  the  platform  in  question. 

•  Target  incidence  angle  and  radar  cross  section  (RCS):  The  base  GMTIF  target  report 
contains  fields  for  target  classification  and  its  probability.  However,  a  sensor  or  its 
groundstation  may  not  have  access  to  enough  information  to  appropriately  classify  a 
target  type.  Hence  the  addition  of  additional  target  properties  like  the  incidence  angle  at 
the  target  and  its  radar  cross  section  to  the  target  report  extension  provides  additional 
information  that  can  be  used  by  an  exploitation  station  to  either  classify  an  unknown 
target,  or  to  update  a  previous  classification  provided  in  the  base  target  report. 

•  Radar  and  processing  parameters:  In  order  to  allow  exploitation  stations  to  perform 
more  detailed  analyses  of  targets  and  their  properties,  it  was  decided  that  additional 
information  was  required  about  certain  parameters  of  both  the  radar  system  and  the 
processing  involved  in  extracting  target  information. 

The  radar  parameters  added  to  the  advanced  job  definition  extension  are  the  carrier 
frequency  and  the  3dB  beamwidths  in  both  azimuth  and  elevation,  which  are  needed  in  a 
number  of  calculations  that  might  be  performed  by  an  exploitation  system. 

A  number  of  useful  processing  parameters  are  also  included  in  the  advanced  segment 
extensions.  These  include  slant  range  resolution  (impulse  response  width)  and  pixel 
spacing,  cross-range  resolution  and  pixel  spacing,  the  range  aliasing  distance  (wrap 
range),  the  minimum  range  of  the  dwell  and  the  terrain  elevation  at  the  centre  of  the 
dwell.  These  allow  an  exploitation  station  to  perform  any  calculations  necessary.  They 
also  provide  a  level  of  redundancy;  that  is,  certain  data  elements  can  be  used  to  cross 
check  other  elements  and  ensure  internal  consistency  of  the  data. 

•  Error  estimates:  Certain  quantities  in  the  base  GMTIF  are  accompanied  by  estimates  of 
the  error  in  that  quantity,  while  others  have  no  associated  error.  It  was  decided  that  it 
would  be  useful  to  include  error  estimates  not  only  for  quantities  added  to  the  advanced 
extensions,  but  also  for  quantities  in  the  base  GMTIF  for  which  no  error  estimates  were 
previously  provided.  The  addition  or  error  estimates  for  all  reported  quantities  should 
provide  powerful  tools  to  assist  in  data-based  decision  making. 
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5  Conclusion 


This  document  has  described  the  development  of  the  GMTIF  STANAG  4607  and  the  philosophy 
behind  it.  Shortcomings  of  the  existing  (airborne)  GMTIF  versions,  such  as  insufficient  support 
for  spacebome  SAR-GMTI  platforms  and  limited  exploitation  capacity,  have  been  identified.  The 
addition  of  advanced  segment  extensions  to  overcome  these  deficiencies  (and  more  specifically, 
to  support  RADARSAT-2  GMTI  data)  has  been  described  in  detail.  This  description  has  included 
the  specification  of  the  advanced  segment  extensions  and  the  justification  for  the  quantities 
contained  therein.  More  specifically,  the  segments  and  extensions  being  implemented  by  the 
RADATSAT-2  GMTI  team  at  DRDC  Ottawa  (and  which  form  the  bulk  of  the  needed  changes 
incoiporated  by  NATO  into  the  GMTIF)  are  presented. 

The  addition  of  these  new  capabilities  to  the  GMTIF  will  provide  an  increased  capacity  to  exploit 
GMTI  data  from  numerous  sensors  on  differing  platforms.  The  utility  of  the  base  (airborne) 
GMTIF,  despite  its  shortcomings,  has  been  shown  in  various  NATO  aerial  interoperability 
exercises,  such  as  those  conducted  under  the  Coalition  Aerial  Surveillance  and  Reconnaissance 
(CAESAR)  &  Multi-sensor  Aerospace-Ground  Joint  ISR  Interoperability  Coalition  (MAJIIC) 
projects  [9,10].  The  addition  of  support  for  spacebome  SAR-GMTI  data  is  expected  to  further 
enhance  the  utility  of  GMTIF  data,  as  the  DRDC  RADARSAT-2  GMTI  group  aims  to 
demonstrate  to  the  CF  in  upcoming  trials,  once  the  satellite  is  launched. 

Overall,  the  enhanced  capabilities  described  in  this  document  were  driven  by  the  needs  of  the 
DRDC  RADARSAT-2  GMTI  project.  In  addition  to  providing  support  for  RADARSAT-2  GMTI 
data  in  the  GMTIF,  they  will  result  in  improved  interoperability  of  joint  and  coalition  forces  using 
GMTI  data.  They  will  also  provide  increased  support  for  the  warfighter,  especially  in  visualizing 
the  exploited  GMTI  data  used  in  support  of  a  common  operational  picture  of  the  battlefield. 
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Annex  A  Edition  2  of  the  base  GMTIF  STANAG  4607 


This  section  provides  tables  and  descriptions  of  the  GMTIF  Packet  and  Segment  Headers  and  the 
Mission,  Dwell,  Job  Definition,  and  Platform  Location  Segments.  The  headers  and  segments 
described  in  this  Annex  are  required  for,  and  form  the  base  of,  the  GMTI  Format.  The  advanced 
extensions  added  to  these  segments  to  support  RADATSAT-2  GMTI  data  are  listed  in  Annex  B. 
Additional  segments  from  the  base  GMTIF,  which  are  not  used  by  RADARSAT-2,  are  not 
shown.  In  the  following  tables,  entries  in  blue  indicate  quantities  which  will  always  be  reported 
by  RADARSAT-2  GMTI,  those  in  green  indicate  quantities  which  can  be  provided  depending  on 
the  users’  needs  and  bandwidth  considerations,  while  those  in  red  will  not  be  implemented  by 
RADARSAT-2  GMTI. 

A.1  Packet  Header 

The  Packet  Header  (Table  A-l)  shall  be  sent  at  the  beginning  of  each  packet.  It  identifies  the 
format  version  of  the  data  contained  in  the  packet,  the  size  of  the  packet,  and  information 
pertaining  to  the  platform,  security,  and  the  mission. 


Table  A-l.  Packet  Header 


Field 

Type 

Field  Name 

Bytes 

Form 

Value 

PI 

M 

4607  Version  ID 

2 

A 

P2 

M 

Packet  Size 

4 

132 

32  to  4294967295 

P3 

M 

Nationality 

2 

A 

CA  (Table  A-3) 

P4 

M 

Packet 

Security 

Data 

Classification 

1 

E8 

Table  A-2 

P5 

M 

Class.  System 

2 

A 

CA  (Table  A-3) 

P6 

M 

Code 

2 

FL 

Table  A-4 

P7 

M 

Exercise  Indicator 

1 

E8 

RADARSAT-2 

P8 

M 

Platform  ID 

10 

A 

Sec  A.  1.8  (TBD) 

P9 

M 

Mission  ID 

4 

132 

Sec  A.  1.9  (TBD) 

P10 

M 

Job  ID 

4 

132 

0,  1  to  4294967295 

A. 1.1  Version  ID  (PI)  (M). 

A  two-character  alphanumeric  code  indicating  the  version  of  STANAG  4607  to  which  the  packet 
conforms. 

It  shall  be  of  the  form  “mn”,  where  “m”  indicates  the  edition  number  and  “n”  indicates  the 
amendment  number  of  that  edition.  For  example,  a  value  of  “10”  indicates  that  it  is  edition  1 
without  any  amendments.  A  value  of  “11”  indicates  that  it  is  the  edition  1  with  amendment 
number  1  incorporated. 
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A. 1.2  Packet  Size  (P2)  (M). 

The  number  of  bytes  in  the  entire  packet ,  including  this  header. 


The  minimum  packet  size  shall  be  the  number  of  bytes  in  the  Packet  Header,  as  shown  in  Table 
A-l. 


A. 1.3  Nationality  (P3)  (Ml. 

A  digraph ,  in  accordance  with  the  Federal  Information  Processing  Standards  (FIPS)  Publication 
10-4:  “Countries,  Dependencies,  Areas  of  Special  Sovereignty,  and  Their  Principal 
Administrative  Divisions  ”,  that  identifies  the  nationality  of  the  platform  providing  GMTI  data. 

The  Country  Codes  are  listed  in  Table  A-3.  NATO  platforms  providing  GMTI  data  shall  use  the 
digraph  XN. 


A.1.4  Packet  Security  -  Classification  (P4)  (M). 

An  enumeration  table  indicating  the  classification  level  of  the  packet. 
Allowable  values  are  shown  in  Table  A-2. 


Table  A-2.  Packet  Security  Classification 


VALUE 

CLASSIFICATION 

1 

TOP  SECRET 

2 

SECRET 

3 

CONFIDENTIAL 

4 

RESTRICTED 

5 

UNCLASSIFIED 

6 

NO  CLASSIFICATION 

A.1.5  Packet  Security  -  Classification  System  (P5)  (M). 

A  digraph  indicating  the  national  or  multinational  security  system  to  which  the  security 
classification  in  field  P4  conforms.  Country  codes  for  national  security  systems  are  in  accordance 
with  FIPS  Publication  10-4. 

Example  values  are  shown  in  Table  A-3.  If  this  field  is  all  BCS  spaces  (hexadecimal  0x20),  it 
indicates  that  no  Security  Classification  System  applies  to  the  file. 
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Table  A-3.  Packet  Classification  Systems 


CLASSIFICATION  SYSTEM 

DIGRAPH 

Country  Codes  defined  in  FIPS 
Publication  10-4 

BE,  CA,  DA,  FR,  GM,  GR,  IS,  IT, 
LL\  NL,  NO,  PO,  SP,  TR,  GB,  US 

NAT O  Security  System 

XN 

Additional  codes 

As  registered  with  the  Custodian 

A.1.6  Packet  Security  -  Code  (P6)  (M). 

A  two-byte  flag  field,  defined  in  Table  A-4,  which  indicates  additional  control  and/or  handling 
instructions  associated  with  the  GMTI  data. 

A  value  of  0  (hex  0x00)  indicates  there  are  no  additional  security  codes  that  apply  to  the  GMTI 
data.  Each  bit  of  the  field,  when  set  to  a  binary  “1”,  indicates  that  the  corresponding  security  code 
in  Table  A-4  applies  to  the  data.  This  field  allows  multiple  security  codes  to  be  associated  with 
the  GMTI  data.  (NOTE:  This  table  is  representative,  based  on  US  security  handling  codes,  and  is 
not  an  exhaustive  list  of  all  allowable  codes.  Each  nation  shall  be  responsible  for  developing  and 
publishing  their  own  packet  security  handling  codes  as  required. 

Table  A-4.  Packet  Security  Codes 


VALUE  (HEX) 

CODEWORD 

0x0000 

NONE  ( NO-STATEMENT  VALUE) 

0x0001 

NOCONTRACT 

0x0002 

ORCON 

0x0004 

PRO  PIN 

0x0008 

WN1NTEL 

0x0010 

NATIONAL  ONLY 

0x0020 

LIMDIS 

0x0040 

FOUO 

0x0080 

EFTO 

0x0100 

LIM  OFF  USE  (UNCLAS) 

0x0200 

NONCOMPARTMENT 

0x0400 

SPECIAL  CONTROL 

0x0800 

SPECIAL  INTEL 

0x1000 

WARNING  NOTICE  -  SECURITY 

CLASSIFICATION  IS  B.ASED  ON  THE  FACT  OF 
EXISTENCE  AND  AVAIL  OF  THIS  DATA 

0x2000 

REL  NATO  (BEL,  BGR,  CAN,  CZE,  DNK,  EST, 

FRA,  DEL.  GRC.  HUN,  1SL,  IT  A,  LVA,  LTU,  LUX, 
NLD,  NOR,  POL,  PRT,  ROU,  SVK,  SVN,  ESP,  TUR, 
GBR,  USA) 

0x4000 

REL  4-EYES  (AUS,  CAN,  GBR,  USA) 

0x8000 

REL  9-EYES  (CAN,  FRA,  DEU,  NLD,  NOR,  ESP, 
TUR,  GBR,  USA) 
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A.1.7  Exercise  Indicator  (P7)  (M). 


An  enumeration  table  indicating  whether  the  data  contained  in  this  packet  is  from  a  real-world 
military  operation  or  from  an  exercise,  and  whether  the  data  is  real  (originates  from  live-fly  or 
other  lion-simulated  operational  sources),  simulated  (originates  from  target  simulator  sources), 
or  synthesized  (a  mix  of  real  and  simulated  data). 

Allowable  values  are  shown  in  Table  A-5. 

Table  A-5.  Exercise  Indicator 


VALUE 

DEFINITION 

0 

Operation,  Real  Data 

1 

Operation,  Simulated  Data 

2 

Operation,  Synthesized  Data 

3-127 

Reserved 

128 

Exercise,  Real  Data 

129 

Exercise,  Simulated  Data 

130 

Exercise,  Synthesized  Data 

131-255 

Reserved 

A. 1.8  Platform  ID  (P8)  (M). 

An  alphanumeric  field  that  identifies  the  platform. 

For  aircraft  the  platform  ID  shall  be  the  tail  number.  For  a  space-based  platform  the  platform  ID 
shall  be  the  satellite  name  with  an  appropriate  numerical  designator.  For  other  systems,  an 
appropriate  unique  designator  shall  be  used.  Unused  bytes  shall  be  filled  with  the  BUS  space 
character  (hex  0x20).  In  all  cases,  the  platform  ID  is  determined  by  the  nation  owning  the 
platform,  whose  responsibility  it  is  to  ensure  that  all  its  platforms  are  uniquely  identified  within 
the  set  of  platforms  it  owns. 

A. 1.9  Mission  ID  (P9)  (M). 

An  integer  field,  assigned  by  the  platform  identified  in  Field  P8,  which  uniquely  identifies  the 
mission  for  the  platform. 

A. 1.10  Job  ID  (P10)  (M). 

A  platform-assigned  number  identifying  the  specific  request  or  task  to  which  the  packet  pertains. 

The  Job  ID  shall  be  unique  within  a  mission.  A  Job  ID  of  0  (hex  0x00)  indicates  there  is  no 
reference  to  any  specific  request  or  task.  If  the  Job  ID  in  the  Packet  Header  is  0  (hex  0x00),  then 
the  packet  can  not  contain  Dwell,  HRR,  or  Range-Doppler  segments. 
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A.2  Segment  Header 


The  Segment  Header  (Table  A-6)  shall  be  sent  at  the  beginning  of  each  segment  transmitted 
within  a  packet.  It  identifies  the  type  and  size  of  the  segment  that  follows. 


Table  A-6.  Segment  Header 


Field 

Type 

Field 

Name 

Bytes 

Form 

Value 

SI 

M 

Segment 

type 

1 

E8 

1=  Mission  Segment 

2=  Dwell  Segment 

3=4  IRR  Segment 

4=Range-Doppler  Segment 

5=  Job  Definition  Segment 

6=  Free  text  Segment 

7=Low  Reflectivity  Index  Segment 
8=Group  Segment 

9=Attached  Target  Segment 

10=Test  and  Status  Segment 

1  l=System  Specific  Segment 
12=Processing  History  Segment 
13=Platform  Location  Segment 
14-100=Reserved  for  new  segments 
101=Job  Acknowledge  Segment 

102= Job  Request  Segment 
103-127=Reserved  for  future  use 
128-255=Reserved  for  extensions 

S2 

M 

Segment 

size 

4 

132 

NOTE:  Refer  to  the  Registry  of  Controlled  Extensions  in  the  NATO  Ground  Moving  Target 
Indicator  (GMTI)  Format  Implementation  Guide,  AEDP-7  [5],  for  additional  segments  which 
have  been  approved  for  use  with  STANAG  4607. 

A.2.1  Segment  Type  (SI)  (M). 

An  enumeration  table  indicating  the  type  and  content  of  the  data  segment  which  follows  this 
header. 

The  enumeration  table  for  Segment  types  is  shown  in  Table  A-6.  Data  segments  corresponding  to 
the  values  4,  7,  8,  9,  11,  14-100,  and  103-255  are  reserved  for  future  use. 

A.2.2  Segment  Size  (S2)  (M). 

Number  of  bytes  in  this  header  and  the  data  segment  which  follows  this  header. 
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It  is  not  to  exceed  the  maximum  packet  size  as  designated  in  field  P2,  Packet  Size,  of  the  Packet 
Header,  minus  the  size  of  the  Packet  Header  itself. 

A.3  Mission  Segment 

The  Mission  Segment  (Table  A-7)  provides  information  concerning  the  mission  and  shall  be  sent 
periodically  at  least  once  every  two  minutes.  It  includes  information  on  the  mission  and  flight 
plans,  the  type  and  configuration  of  the  platform,  and  the  reference  time.  Note  that  the  Dwell 
Time  (field  D6)  specified  in  any  associated  Dwell  Segments  is  referenced  to  the  Reference  Time 
(fields  M5-M7)  in  the  Mission  Segment,  and  will  not  be  resolved  as  to  the  day  of  the  mission 
until  the  Mission  Segment  is  received  from  the  transmitting  platform. 


Table  A-7.  Mission  Segment 


Field 

Type 

Field  Name 

Bytes 

Form 

Value 

Ml 

M 

Mission  Plan 

12 

A 

Sec.  A.3.1  (TBD) 

M2 

M 

Flight  Plan 

12 

A 

Sec.  A.3.2  (TBD) 

M3 

Platform  Type 

1 

E8 

Table  A-8  (10) 

M4 

M 

Platform  Configuration 

10 

A 

Sec.  A.3. 4  (TBD) 

M5 

M 

Reference 

Time 

Year 

2 

116 

eg.  2007 

M6 

M 

Month 

1 

18 

1  to  12 

M7 

M 

Day 

1 

18 

1  to  31 

A.3.1  Mission  Plan  (Ml)  (Ml. 

An  alphanumeric  field  that  identifies  the  mission,  and  which  shall  be  unique  for  all  the  missions 
defined  for  that  platform. 

For  aircraft  or  land-based  systems,  the  Mission  Number  from  the  Air  Tasking  Order  (ATO)  or  an 
equivalent  document  shall  be  used.  For  space-based  platforms,  the  mission  identifier  or  a  suitable 
designator  such  as  “yymmhhnn”,  where  yy  (year),  mm  (month),  and  hh  (hour)  indicate  the  time 
the  collection  mission  began  and  nn  is  the  identifying  number  of  the  satellite,  shall  be  used.  If 
there  is  no  Mission  Plan  to  be  sent,  or  if  there  are  unused  bytes  in  the  field,  the  field  shall  be  filled 
with  the  BCS  space  character  (hex  0x20). 

A.3.2  Flight  Plan  (M2)  (M). 

An  alphanumeric  field  that  identifies  the  flight  plan. 

This  field  provides  a  unique  identification  of  the  flight  plan.  If  the  flight  plan  is  not  available  from 
the  ATO  or  an  equivalent  source,  a  suitable  unique  identifier  may  be  inserted  in  this  field.  If  there 
is  no  Flight  Plan  to  be  sent,  or  if  there  are  unused  bytes  in  the  field,  the  field  shall  be  filled  with 
the  BCS  space  character  (hex  0x20). 
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A.3.3  Platform  Type  (M3)  (M). 

An  enumeration  table  that  identifies  the  type  of  platform  that  originated  the  data  (Table  A-8). 


Table  A-8.  Platform  Types 


PLATFORM 

VALLE 

Unidentified 

0 

ACS 

1 

ARL-M 

2 

Sentinel  (was  ASTOR) 

3 

Rotary  Wing  Radar  (was  CRESOi 

4 

Global  Hawk-Navy 

5 

HORIZON 

6 

E-8  (Joint  STARS) 

7 

P-3C 

8 

Predator 

9 

RADARSAT2 

10 

U-2 

11 

E-10  (was  MC2 A) 

12 

UGS  -  Single 

13 

UGS  -  Cluster 

14 

Ground  Based 

15 

UAV-Army 

16 

UAV-Mannes 

17 

UAV-Navy 

18 

UAV-Air  Force 

19 

Global  Hawk-  Air  Force 

20 

Global  Hawk -Australia 

21 

Global  Hawk -Germany 

22 

Paul  Rev  ere 

23 

Mariner  UAV 

24 

BAC-1 1 1 

25 

Coyote 

26 

King  Air 

27 

LIMIT 

28 

NRL  NP-3B 

29 

SOSTAR-X 

30 

WatchKeeper 

31 

Alliance  Ground  Surveillance  (AGS)  (A32 1 ) 

32 

Stryker 

33 

AGS  (HALE  UAV) 

34 

S1DM 

35 

Reaper 

36 

W  arrior  A 

37 

Warrior 

38 

Available  for  Future  Use 

39-254 

Other 

255 

DRDC  Ottawa  TM  2007-341 


21 


A.3.4  Platform  Configuration  (M4)  (M). 

An  alphanumeric  field  indicating  the  particular  variant  of  the  platform. 

It  identifies  sensor  complements,  upgrades,  or  other  identifying  information.  Examples  would  be 
a  model  number,  software  release  number,  clarifications  of  differences  in  platform  types,  or 
identification  of  the  platform  as  a  test  article.  A  recommended  default  value  is  an  identification  of 
the  software  and/or  hardware  version.  If  there  is  no  Platform  Configuration  to  be  sent,  the  fields 
shall  be  filled  with  the  BCS  space  character  (hex  0x20). 

A.3.5  Reference  Time  -  Year  (M5)  (M). 

The  year  in  which  the  mission  originated. 

For  airborne  platforms,  this  shall  be  the  takeoff  time.  For  spacebome  platforms,  this  shall  be  an 
epoch  time,  which  shall  be  selected  suitable  for  the  collection.  For  ground-based  platforms,  a  time 
reference  suitable  for  collection  shall  be  selected. 

A.3.6  Reference  Time  -  Month  (M6)  (M). 

The  month  of  the  year  in  which  the  mission  originated.  For  airborne  platforms,  this  shall  be  the 
takeoff  time.  For  spacebome  platforms,  this  shall  be  an  epoch  time,  which  shall  be  selected 
suitable  for  the  collection.  For  ground-based  platforms,  a  time  reference  suitable  for  collection 
shall  be  selected. 

A.3.7  Reference  Time  -  Day  (M7)  (M). 

The  day  of  the  month  in  which  the  mission  originated. 

For  airborne  platforms,  this  shall  be  the  day  of  takeoff.  For  satellite  platforms,  this  shall  be  an 
epoch  time,  which  shall  be  selected  suitable  for  the  collection.  For  ground-based  platforms,  a  time 
reference  suitable  for  collection  shall  be  selected. 

Note  that  the  Dwell  Time  fields,  D6  in  the  Dwell  Segment  and  T4  in  the  Test  and  Status  Segment, 
are  obtained  as  the  count  in  milliseconds  from  the  time  00:00:00  UTC  of  this  day.  The  maximum 
value  of  field  D6  is  equivalent  to  49  days.  Therefore,  to  prevent  the  time  stamp  in  field  D6  from 
being  repeated,  a  new  mission  day  must  be  provided  every  49  days  or  more  frequently. 

A.4  Job  Definition  Segment 

The  Job  Definition  Segment  (Table  A-9)  provides  the  means  for  the  platform  to  pass  information 
pertaining  to  the  sensor  job  that  will  be  performed  and  details  of  the  location  parameters  (terrain 
elevation  model  and  geoid  model)  used  in  the  measurement.  It  includes  a  definition  of  the 
geographic  area  for  sensor  service,  the  Bounding  Area,  which  is  defined  as  a  four-comer  polygon, 
with  the  four  points  of  the  polygon  chosen  to  define  a  convex  quadrilateral. 
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The  Bounding  Area  shall  remain  fixed  for  a  given  Job  ID.  The  Job  Definition  Segment  shall  be 
sent  before  the  first  revisit  of  a  job  and  shall  be  sent  periodically  at  least  once  every  30  seconds 
thereafter.  Note  that  precision  location  of  a  target  will  not  be  possible  until  the  information 
contained  in  the  Job  Definition  segment  has  been  received  from  the  transmitting  platform. 


Table  A-9.  Job  Definition  Segment 


Field 

Type 

Field  Name 

Bytes 

Form 

Value 

Units 

J1 

M 

Job  ID 

4 

132 

1  to  4294967295 

bytes 

J2 

M 

Sensor 

Type 

1 

E8 

Table  A- 10  (10) 

J3 

M 

ID 

Model 

6 

A 

Sec  A.4.3  (GMTI) 

J4 

M 

Target  Filter  Flag 

1 

FL8 

Sec  A.4.4  (0) 

J5 

M 

Priority  (rac 

ar  priority) 

1 

18 

Sec  A.4.5  (1) 

J6 

M 

Bounding 

A  Lat 

4 

SA32 

-  90  to  +89.999989 

degrees 

J7 

M 

Area 

A  Long 

4 

BA32 

0  to  +359.999979 

degrees 

J8 

M 

B  Lat 

4 

SA32 

-  90  to  +89.999989 

degrees 

J9 

M 

B  Long 

4 

BA32 

0  to  +359.999979 

degrees 

J10 

M 

C  Lat 

4 

SA32 

-  90  to  +89.999989 

degrees 

Jll 

M 

C  Long 

4 

BA32 

0  to  +359.999979 

degrees 

J12 

M 

D  Lat 

4 

SA32 

-  90  to  +89.999989 

degrees 

J13 

M 

D  Long 

4 

BA32 

0  to  +359.999979 

degrees 

J14 

M 

Radar  Mode 

1 

E8 

Table  A- 11  (1) 

J15 

M 

Revisit  interval 

2 

116 

0,1  to  65535 

deciseconds 

J16 

M 

Nominal 

Along 

2 

116 

0  to  10000 

decimetres 

Sensor 

track 

0  to  10000 

decimetres 

J17 

M 

Position 

Cross  track 

2 

116 

0  to  20000 

decimetres 

J18 

M 

Uncertaint 

Altitude 

2 

116 

0  to  45 

degrees 

J19 

M 

y 

Track 

Heading 

1 

18 

0  to  65534 

millimetres/sec 

J20 

M 

Sensor 

speed 

2 

116 

J21 

M 

Nominal 

S 

ant  Range 

2 

116 

0  to  65534 

centimetres 

Sensor 

SD 

J22 

M 

Value 

Cross  Range 

2 

BA16 

Oto  179.9945 

degrees 

SD 

centimetres/sec 

J23 

M 

Radial  Vel. 

2 

B16 

0  to  5000 

SD 

0  to  254 

J24 

M 

MDV 

1 

18 

decimetres/sec 

J25 

M 

Pd 

1 

18 

0  to  100 

percent 

J26 

M 

PpA 

1 

18 

0  to  254 

Negative  dB 

ill 

M 

Terrain  Elevation  Model 

1 

E8 

Table  A- 12 

J28 

M 

Geoid  Model 

1 

E8 

Table  A- 13 
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A. 4.1  Job  ID  (J1)  (M). 

A  platform  assigned  number  identifying  the  specific  request  or  task  to  which  the  dwell  pertains. 


A.4.2  Sensor  ID  -  Type  (J2)  m). 

An  enumeration  table  denoting  the  type  of  sensor  or  the  platform. 

Current  sensor  types  are  listed  in  Table  A- 10.  A  Sensor  ID  -  Type  value  of  “255”  indicates  that  it 
is  a  No  Statement  and  no  sensor  type  is  specified.  New  sensor  types  shall  be  registered  with  the 
Custodian. 


Table  A- 10.  Sensor  Types 


SENSOR 

VALUE 

Unidentified 

0 

Other 

1 

HiSAR 

2 

ASTOR 

3 

Rotary  Wing  Radar  (was  CRESO) 

4 

Global  Hawk  Sensor 

5 

HORIZON 

6 

APY-3 

•7 

APY-6 

8 

APY-8  (Lynx  1) 

9 

RADARSAT2 

10 

ASARS-2A 

11 

TESAR 

12 

MP-RT1P 

13 

APG-77 

14 

APG-79 

15 

APG-81 

16 

APY*6v  1 

17 

DPY-1  (Lynx  11) 

18 

S1DM 

19 

LIMIT 

20 

TCAR  (AGS  A321 ) 

21 

LSRS  Sensor 

22 

UGS  Single  Sensor 

23 

UGS  Claster  Sensor 

24 

Available  for  Future  Use 

25-254 

No  Statement 

255 
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A.4.3  Sensor  ID  -  Model  (J3)  (M). 

An  Alphanumeric  field  identifying  the  particular  variant  of  the  sensor  type. 

A.4.4  Target  Filtering  Flag  (J4)  (M). 

A  flag  field  indicating  whether  or  not  filtering  has  been  applied  to  the  targets  detected  within  the 
dwell  area  and  the  type  of filtering,  if  any,  that  has  been  applied. 

A  Target  Filtering  Flag  of  zero  (hex  0x00)  indicates  that  no  filtering  has  been  applied  to  the 
targets. 

If  bit  0,  the  least  significant  bit,  is  set  to  a  binary  “one”,  this  indicates  that  area  filtering  within  the 
intersection  of  the  Dwell  Area  and  the  Bounding  Area  has  been  performed. 

If  bit  1  is  set  to  a  binary  “one”,  this  indicates  that  Area  blanking  has  been  applied.  However,  the 
format  does  not  currently  specify  the  sector  over  which  blanking  has  been  applied. 

If  bit  2  is  set  to  a  binary  “one”,  this  indicates  that  Sector  Blanking  has  been  applied.  However,  the 
format  does  not  currently  specify  the  sector  over  which  blanking  has  been  applied. 

Bits  number  3-7  shall  be  reserved  for  future  growth. 

A.4.5  Priority  (Radar  Priority)  (J5)  (M). 

Specifies  the  priority  of  this  tasking  request  relative  to  all  other  active  tasking  requests  scheduled 
for  execution  on  the  specified  platform . 

A  value  of  255  indicates  the  Job  is  ended. 

A.4.6  Bounding  Area  -  Point  A  Latitude  (J6)  M. 

The  North-South  position  of  the  first  corner  (Point  A)  defining  the  area  for  sensor  sendee, 
expressed  as  degrees  North  (positive)  or  South  (negative)  of  the  Equator. 

The  four  corners  (J6  through  J13)  of  the  bounding  area,  expressed  as  lat/long  for  each  comer,  are 
given  in  clockwise  order  (Points  A,  B,  C,  and  D)  and  must  form  a  convex  quadrilateral. 

A.4.7  Bounding  Area  -  Point  A  Longitude  (J7)  M. 

The  East-West  position  of  the  first  corner  (Point  A)  defining  the  area  for  sensor  sendee, 
expressed  as  degrees  East  (positive)  of  the  Prime  Meridian. 

The  four  corners  (J6  through  J13)  of  the  bounding  area,  expressed  as  lat/long  for  each  comer,  are 
given  in  clockwise  order  (Points  A,  B,  C,  and  D)  and  must  form  a  convex  quadrilateral. 
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A.4.8  Bounding  Area  -  Point  B  Latitude  (J8)  M. 


The  North-South  position  of  the  second  corner  (Point  B)  defining  the  area  for  sensor  service, 
expressed  as  degrees  North  (positive)  or  South  (negative)  of  the  Equator. 

The  four  comers  (J6  through  J13)  of  the  bounding  area,  expressed  as  lat/long  for  each  comer,  are 
given  in  clockwise  order  (Points  A,  B,  C,  and  D)  and  must  form  a  convex  quadrilateral. 

A.4.9  Bounding  Area  -  Point  B  Longitude  (J9)  M. 

The  East-West  position  of  the  second  corner  (Point  B)  defining  the  area  for  sensor  service, 
expressed  as  degrees  East  (positive)  of  the  Prime  Meridian. 

The  four  comers  (J6  through  J13)  of  the  bounding  area,  expressed  as  lat/long  for  each  comer,  are 
given  in  clockwise  order  (Points  A,  B,  C,  and  D)  and  must  form  a  convex  quadrilateral. 

A.4.10  Bounding  Area  -  Point  C  Latitude  (J10)  M. 

The  North-South  position  of  the  third  corner  (Point  C)  defining  the  area  for  sensor  service, 
expressed  as  degrees  North  (positive)  or  South  (negative)  of  the  Equator. 

The  four  corners  (J6  through  J13)  of  the  bounding  area,  expressed  as  lat/long  for  each  comer,  are 
given  in  clockwise  order  (Points  A,  B,  C,  and  D)  and  must  form  a  convex  quadrilateral. 

A.4.11  Bounding  Area  -  Point  C  Longitude  (J11)  M. 

The  East-West  position  of  the  third  corner  (Point  C)  defining  the  area  for  sensor  service, 
expressed  as  degrees  East  (positive)  of  the  Prime  Meridian. 

The  four  corners  (J6  through  J13)  of  the  bounding  area,  expressed  as  lat/long  for  each  comer,  are 
given  in  clockwise  order  (Points  A,  B,  C,  and  D)  and  must  form  a  convex  quadrilateral. 

A.4.12  Bounding  Area  -  Point  D  Latitude  (J12)  M. 

The  North-South  position  of  the  fourth  corner  (Point  D)  defining  the  area  for  sensor  service, 
expressed  as  degrees  North  (positive)  or  South  (negative)  of  the  Equator. 

The  four  corners  (J6  through  J13)  of  the  bounding  area,  expressed  as  lat/long  for  each  comer,  are 
given  in  clockwise  order  (Points  A,  B,  C,  and  D)  and  must  form  a  convex  quadrilateral. 

A.4.13  Bounding  Area  -  Point  D  Longitude  (J13)  M. 

The  East-West  position  of  the  fourth  corner  (Point  D)  defining  the  area  for  sensor  service, 
expressed  as  degrees  East  (positive)  of  the  Prime  Meridian. 
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The  four  comers  (J6  through  J 13)  of  the  bounding  area,  expressed  as  lat/long  for  each  comer,  are 
given  in  clockwise  order  (Points  A,  B,  C,  and  D)  and  must  form  a  convex  quadrilateral. 


A.4.14  Radar  Mode  (J14)  (M). 

An  enumeration  table  that  identifies  the  mode  in  which  the  radar  will  operate  for  a  given  job  ID. 

Radar  operating  modes  are  system  specific  and  shall  be  determined  for  each  system.  Table  A- 11 
provides  a  list  of  system  specific  radar  operating  modes. 

Table  A-l  1 .  Radar  Modes 


RADAR  MODE 

SYSTEM 

VALUE 

RADAR  MODE 

SYSTEM 

VALUE 

Unspecified  Mode 

Generic 

0 

EMT1  Augmented  Spot 

ASARS-2 

54 

MTI  (Moving  target 

Indicator) 

Generic 

1 

EMT1  Wide  Area  MTI 
(WAMTI) 

.ASARS-2 

55 

HRR  (High  Range 
Resolution) 

Generic 

2 

Available  for  Future  Use 

Reserved 

56-60 

L'HRR  (Ultra  High  Range 
Resolution) 

Generic 

3 

GMT I  PPI  Mode 

TUAV 

61 

HL'R  (High  Update  Rate) 

Generic 

4 

GMTI  Expanded  Mode 

TUAV 

62 

FTI 

Generic 

5 

Narrow  Sector  Search 
(NSS) 

ARL-M 

63 

Available  forFuture  Use 

Reserved 

6-10 

Single  Beam  Scan  (SBS) 

ARL-M 

64 

Attack  Control  —  SATC 

Joint  STARS 

11 

Wide  Area  ( WA) 

ARL-M 

65 

Attack  Control 

Joint  STARS 

12 

Available  for  Future  Use 

Reserved 

66-80 

SATC 

Joint  STARS 

13 

GRCA 

Reserved 

81 

Attack  Planning  -  SATC 

Joint  STARS 

14 

RRCA 

Reserved 

82 

Attack  Planning 

Joint  STARS 

15 

Sector  Search 

Reserved 

83 

Medium  Resolution  Sector 
Search 

Joint  STARS 

16 

HORIZON  Basic 

HORIZON 

84 

Low  Resolution  Sector 

Search 

Joint  STARS 

17 

HORIZON  High  Sensitivity 

HORIZON 

85 

Wide  Area  Search  •  GRCA 

Joint  STARS 

18 

HORIZON  Bum  Through 

HORIZON 

86 

Wide  Area  Search  -  RRCA 

Joint  STARS 

19 

CRESO  Acquisition 

CRESO 

87 

Attack  Planning-  With 
Tracking 

Joint  STARS 

20 

CRESO  Count 

CRESO 

88 

Attack  Control  —  With 
Tracking 

Joint  STARS 

21 

Available  for  Future  Use 

Reserved 

89-93 

Available  for  Future  Use 

Reserved 

22-30 

MTI  EXO 

ASTOR 

94 

Wide  Area  MTI  (WAMTI) 

ASARS-AIP 

31 

MTI  ENDO/EXO 

ASTOR 

95 

Coarse  Resolution  Search 

ASARS-A1P 

32 

Available  for  Future  Use 

Reserved 

96-99 

Medium  Resolution  Search 

ASARS-AIP 

33 

Test  Status  Mode 

Reserved 

100 

High  Resolution  Search 

ASARS-AIP 

34 

MTI  Spot  Scan 

Lynx  IT I 

101 

Point  Imaging 

ASARS-AIP 

35 

MTI  .Arc  Scan 

Lynx  I/I  I 

102 

Swath  MTI  (SMTI) 

ASARS-AIP 

36 

HRR  MTI  Spot  Scan 

Lynx  I/I  I 

103 

Repetitive  Point  Imaging 

ASARS-AIP 

37 

HRR  MTI  .Arc  Scan 

Lynx  I  II 

104 

Monopulse  Calibration 

ASARS-AIP 

38 

Available  for  Future  Use 

Reserved 

105-1  10 

Available  for  Future  Use 

Reserved 

39-50 

GRCA 

Global  Hawk 

111 

Search 

ASARS-2 

51 

RRCA 

Global  Hawk 

112 

EMT1  Wide  Frame  Search 

ASARS-2 

52 

GMTI-HRR 

Global  Hawk 

113 

EMT1  Narrow  Frame 

Search 

ASARS-2 

53 

Available  for  Future  Use 

Reserved 

114-255 
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A.4.15  Nominal  Revisit  Interval  (J15)  (M). 

Specifies  the  nominal  revisit  interval  for  the  job  ID,  expressed  in  deciseconds  (tenths  of  seconds). 

A.4.16  Nominal  Sensor  Position  Uncertainty  -  Along  Track  (J16)  (M). 

Nominal  estimate  of  the  standard  deviation  in  the  estimated  horizontal  sensor  location,  expressed 
in  decimetres.  It  is  measured  along  the  sensor  track  direction  defined  in  field  D15  of  the  Dwell 
segment. 

The  No-Statement  value  is  sent  when  the  sensor  is  unable  or  unwilling  to  provide  a  value. 
(NOTE:  The  nominal  fields  in  the  Job  Definition  Segment  provide  a  means  for  reporting  nominal 
standard  deviations  and  uncertainty  values,  and  are  to  be  used  when  values  are  not  received  by  the 
sensor.  More  precise  values  of  these  or  related  estimates  may  be  reported  in  the  appropriate  fields 
in  either  the  Dwell  Segment  or  the  Target  Report  Sub- Segment,  when  the  sensor  computes  them 
and  the  communication  bandwidth  permits  the  more  frequent  reporting.) 

A.4.17  Nominal  Sensor  Position  Uncertainty  -  Cross  Track  (J17)  (M). 

Nominal  estimate  of  the  standard  deviation  in  the  estimated  horizontal  sensor  location,  measured 
orthogonal  to  the  track  direction,  expressed  in  decimetres. 

The  No-Statement  value  is  sent  when  the  sensor  is  unable  or  unwilling  to  provide  a  value. 

A.4.18  Nominal  Sensor  Position  Uncertainty  -  Altitude  (J18)  (M). 

Nominal  estimate  of  the  standard  deviation  of  the  measured  sensor  altitude  (field  Dll),  expressed 
in  decimetres. 

The  No-Statement  value  is  sent  when  the  sensor  is  unable  or  unwilling  to  provide  a  value. 

A.4.19  Nominal  Sensor  Position  Uncertainty  -  Track  Heading  (J19)  (M). 

Nominal  standard  deviation  of  the  estimate  of  sensor  track  heading,  expressed  in  degrees. 

The  No-Statement  value  is  sent  when  the  sensor  is  unable  or  unwilling  to  provide  a  value. 

A.4.20  Nominal  Sensor  Position  Uncertainty  -  Sensor  Speed  (J20)  (M). 

Nominal  standard  deviation  of  the  estimate  of  sensor  speed,  expressed  in  millimetres  per  second. 
The  No-Statement  value  is  sent  when  the  sensor  is  unable  or  unwilling  to  provide  a  value. 
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A.4.21  Nominal  Sensor  Value  -  Slant  Range  Standard  Deviation  (J21)  (M). 

Nominal  standard  deviation  of  the  slant  range  of  the  reported  detection,  expressed  in  metres. 

The  No-Statement  value  is  sent  when  the  sensor  is  unable  or  unwilling  to  provide  a  value. 

A.4.22  Nominal  Sensor  Value  —  Cross  Range  Standard  Deviation  (J22) 
(M). 

Nominal  standard  deviation  of  the  measured  cross  angle  to  the  reported  detection,  expressed  in 
degrees  as  a  16-bit  unsigned  binary  angle. 

The  No-Statement  value  is  sent  when  the  sensor  is  unable  or  unwilling  to  provide  a  value. 

A.4.23  Nominal  Sensor  Value  — Target  Velocity  Line-of-Sight  Component 
Standard  Deviation  (J23)  (M). 

Nominal  standard  deviation  of  the  velocity  line-of-sight  component  reported  in  field  D32.7, 
expressed  in  centimetres  per  second. 

The  No-Statement  value  is  sent  when  the  sensor  is  unable  or  unwilling  to  provide  a  value. 

A.4.24  Nominal  Sensor  Value  — MDV  (J24)  (M). 

Nominal  minimum  velocity  component  along  the  line  of  sight,  which  can  be  detected  by  the 
sensor,  expressed  in  decimetres  per  second. 

The  No-Statement  value  is  sent  when  the  sensor  is  unable  or  unwilling  to  provide  a  value. 

A.4.25  Nominal  Sensor  Value  — Detection  Probability  (J25)  (M). 

Nominal  probability  that  an  unobscured  ten  square-metre  target  will  be  detected  within  the  given 
area  of  surveillance,  assuming  the  Swerling  model  appropriate  for  the  particular  radar  target. 

The  No-Statement  value  is  sent  when  the  sensor  is  unable  or  unwilling  to  provide  a  value. 

A.4.26  Nominal  Sensor  Value  — False  Alarm  Density  (J26)  (M). 

The  expected  density  of  False  Alarms  (FA),  expressed  in  decibels  (-10  loglO(d),  where  d  is  in 
False  Alarms  per  square  metre). 

“0”  represents  1  FA/m2 ,  and  60  represents  1 0  6  FA! m 1  (i.e.  1  FA! km2). 
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A.4.27  Terrain  Elevation  Model  Used  (J27)  (M). 


An  enumeration  field  indicating  the  terrain  elevation  model  used  for  developing  the  target 
reports. 

The  enumeration  table  for  the  terrain  elevation  model  is  shown  in  Table  A-12. 

Table  A-12.  Terrain  Elevation  Models 


VALUE 

TERRAIN  ELEVATION  MODEL 

0 

None  Specified 

1 

DTEDO  (Digital  Terrain  Elevation  Data,  Level  0) 

2 

DTED 1  (Digital  Terrain  Elevation  Data,  Level  1 ) 

3 

DTED2  (Digital  Terrain  Elevation  Data,  Level  2) 

4 

DTED3  (Digital  Terrain  Elevation  Data,  Level  3) 

5 

DTED4  (Digital  Terrain  Elevation  Data,  Level  4) 

6 

DTED5  (Digital  Terrain  Elevation  Data,  Level  5) 

*7 

SRTMI  (Shuttle  Radar  Topography  Mission,  Level  1) 

8 

SRTM2  (Shuttle  Radar  Topography  Mission,  Level  2) 

9 

DGM50M745  (Digtales  Gelandemodell  1:50000) 

10 

DGM250  (Digitales  Gelandemodell  1 :250  000) 

1 1 

ITHD  (Interferometric  Terrain  Data  Height) 

12 

ST  HD  (  Stereometric  Terrain  Data  Height) 

13 

SEDR1S  ( SEDRIS  Reference  Model,  ISO  IEC  18026 

14-255 

Reserved 

A.4.28  Geoid  Model  Used  (J28)  (Ml. 

An  enumeration  field  indicating  the  geoid  model  used  for  developing  the  target  reports. 

The  geoid  model  gives  an  estimate  of  mean  sea  level  via  a  model  for  the  difference  between  the 
earth's  zero-altitude  gravity  potential  and  the  WGS  84  ellipsoid.  If  this  field  is  set,  the  geodetic 
height  field  D32.6  shall  be  interpreted  as  an  orthometric  height  (i.e.  height  above  mean  sea  level), 
regardless  of  the  status  of  the  elevation  model  field  J27.  The  enumeration  table  for  the  terrain 
elevation  model  is  shown  in  A- 13 


Table  A-13.  Geoid  Models 


VALUE 

GEOID  MODEL 

0 

None  Specified 

1 

EGM96  (Earth  Gravitational  Model,  Version  1996) 

2 

GE096  (Geoid  Gravitational  Model,  Version  1996) 

3 

Flat  Earth 

4-255 

Reserved 
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A.5  Dwell  Segment  and  Target  Reports 


A  Dwell  Segment  is  a  report  on  a  grouping  of  zero  or  more  target  reports  for  which  the  sensor 
provides  a  single  time,  sensor  position,  reference  position  on  the  ground  with  simple  estimates  for 
the  observed  area  at  the  reported  time,  and  other  pertinent  data.  A  Dwell  Segment  may  be 
associated  with  a  radar  dwell  but  need  not  be.  The  Dwell  Segment  (Table  A- 14)  presents  data 
pertinent  to  MTI  targets.  Dwell  Segments  shall  be  sent  for  each  logical  grouping  of  target  reports. 
A  Dwell  Segment  shall  be  transmitted  even  if  no  targets  are  observed.  A  Dwell  Segment  may  be 
sent  only  if  the  Job  ID  in  the  associated  Packet  Header  is  not  equal  to  zero  (hex  0x00). 


Table  A- 14.  Dwell  Segment 


Field 

Type 

Field  Name 

Bytes 

Form 

Values 

Units 

D1 

M 

Existence  Mask 

8 

FL64 

Table  A- 15 

D2 

M 

Revisit  index 

2 

116 

0  to  65535 

D3 

M 

Dwell  index 

2 

116 

0  to  65535 

D4 

M 

Last  Dwell  of  revisit 

1 

FL8 

0,1 

Flag  Bit 

D5 

M 

Target  report  count 

2 

116 

0  to  65535 

D6 

M 

Dwell  time 

4 

132 

0  to  4  x  10E9 

milliseconds 

D7 

M 

Sensor 

Latitude 

4 

SA32 

-90  to  +89.999999958 

degrees 

D8 

M 

position 

Longitude 

4 

BA32 

0  to +359.999999916 

degrees 

D9 

M 

Altitude 

4 

S32 

-10000  to  +2  billion 

centimetres 

D10 

C 

Scale  factor 

Lat  scale 

4 

132 

Sec  A.5. 10 

degrees 

Dll 

C 

Long  scale 

4 

132 

Sec  A.5. 11 

degrees 

D12 

0 

Sensor 

Along  track 

4 

132 

0  to  1,000,000 

centimetres 

D13 

0 

Position 

Cross  track 

4 

132 

0  to  1,000,000 

centimetres 

D14 

0 

uncertainty 

Altitude 

2 

116 

0  to  20,000 

decimetres 

D15 

c 

Sensor  track 

2 

BA16 

0  to  359.9945 

degrees 

D16 

c 

Sensor  speed 

4 

132 

0  to  8000000 

millimetres/sec 

D17 

c 

Sensor  vertical  velocity 

1 

18 

-128  to +127 

decimetres/sec 

D18 

0 

Sensor  track  uncertainty 

1 

18 

0  to  45 

degrees 

D19 

0 

Sensor  speed  uncertainty 

2 

116 

0  to  65535 

millimetres/sec 

D20 

0 

Vertical  velocity  uncertainty 

2 

116 

0  to  65535 

centimetres/sec 

D21 

c 

Platform 

Heading 

2 

BA16 

0  to  359.9945 

degrees 

D22 

c 

Orientation 

Pitch 

2 

SA16 

-90  to  +89.9973 

degrees 

D23 

c 

Roll 

2 

SA16 

-90  to  +89.9973 

degrees 

D24 

M 

Center  Lat 

4 

SA32 

-90  to  +  89.999989 

degrees 

D25 

M 

Dwell  Area 

Center  Long 

4 

BA32 

0  to  +359.999979 

degrees 

D26 

M 

Range  half  width 

2 

B16 

0  to  255.9928 

kilometres 

D27 

M 

Dwell  ang.  half  width 

2 

BA16 

0  to  359.9945 

degrees 

D28 

O 

Sensor 

Heading 

2 

BA16 

0  to  359.9945 

degrees 

D29 

O 

Orientation 

Roll 

2 

SA16 

-90  to  +89.9973 

degrees 

D30 

0 

Pitch 

2 

SA16 

-90  to  +89.9973 

degrees 

D31 

0 

Minimum  detectable  velocity 

1 

18 

0  to  255 

decimetres/sec 

D32 

<Target  Reports> 
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A.5.1  Existence  Mask  (D1)  (M). 


The  Existence  Mask,  the  first  field  of  the  Dwell  Segment,  is  an  encoded  eight-byte  field  that 
immediately  follows  the  Segment  Header  fields  and  precedes  all  other  Dwell  Segment  fields.  Each 
field  of  the  Dwell  Segment,  with  the  exception  of  the  Existence  Mask  itself,  is  represented  by  a 
reserved  bit  within  the  Existence  Mask.  Each  bit  of  the  Existence  Mask  indicates  whether  or  not 
the  corresponding  field  of  the  Dwell  Segment  is  present  in  the  data  stream. 

The  most-significant  bit  (bit  7)  of  the  high-order  byte  (byte  7)  corresponds  to  the  first  field  (D2) 
following  the  Existence  Mask  of  the  Dwell  Segment,  where  the  high-order  byte  shall  be 
transmitted  first.  Table  A- 15  illustrates  the  mapping  of  each  Dwell  Segment  field  to  the 
corresponding  bit  position  in  the  8-byte  Existence  Mask.  A  binary  level  of  “  1  ”  for  a  given  bit 
indicates  that  the  corresponding  field  of  the  Dwell  Segment  is  present  in  the  data  stream  and  a 
binary  level  of  “0”  indicates  that  it  is  not  present.  Unused  bits  shall  be  filled  with  zeroes. 
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Table  A-15.  Dwell  Segment  Existence  Mask  Mapping 


Byte 

No. 

Bit 

No. 

Field 

No. 

Type 

Value 

Byte 

No. 

Bit 

No. 

Reid 

No. 

Type 

Value 

7 

7 

D2 

M 

1 

3 

7 

D32.3 

C 

0,1 

7 

6 

D3 

M 

1 

3 

6 

D32.4 

C 

0,1 

7 

5 

D4 

M 

1 

3 

5 

D32.5 

C 

0,1 

7 

4 

D5 

M 

1 

3 

4 

D32.6 

O 

0,1 

7 

“y 

3 

D6 

M 

1 

•y 

3 

3 

D32.7 

O 

0,1 

7 

2 

D7 

M 

1 

•y 

3 

2 

D32.8 

O 

0,1 

7 

i 

D8 

M 

1 

3 

i 

D32.9 

O 

0,1 

7 

0 

D9 

M 

1 

3 

0 

D32. 10 

O 

0,1 

6 

7 

DIO 

C 

0,1 

2 

7 

D32.ll 

O 

0,1 

6 

6 

Dll 

C 

0,1 

2 

6 

D32. 12 

C 

0,1 

6 

5 

D12 

o 

0,1 

2 

5 

D32.13 

C 

0,1 

6 

4 

D13 

o 

0,1 

2 

4 

D32.14 

C 

0,1 

6 

3 

D14 

o 

0,1 

2 

3 

D32.15 

C 

0,1 

6 

2 

D15 

c 

0,1 

2 

2 

D32.16 

O 

0,1 

6 

i 

D16 

c 

0,1 

2 

i 

D32.17 

O 

0,1 

6 

0 

D17 

c 

0,1 

2 

0 

Spare 

N/A 

0 

5 

7 

D18 

o 

0,1 

i 

7 

Spare 

N/A 

0 

5 

6 

D19 

o 

0,1 

i 

6 

Spare 

N/A 

0 

5 

5 

D20 

o 

0,1 

i 

5 

Spare 

N/A 

0 

5 

4 

D21 

c 

0,1 

i 

4 

Spare 

N/A 

0 

5 

3 

D22 

c 

0,1 

i 

3 

Spare 

N/A 

0 

5 

2 

D23 

c 

0,1 

i 

2 

Spare 

N/A 

0 

5 

i 

D24 

M 

1 

i 

i 

Sparc 

N/A 

0 

5 

0 

D25 

M 

1 

i 

0 

Spare 

N/A 

0 

4 

7 

D26 

M 

1 

0 

7 

Spare 

N/A 

0 

4 

6 

D27 

M 

1 

0 

6 

Spare 

N/A 

0 

4 

5 

D28 

O 

0,1 

0 

5 

Spare 

N/A 

0 

4 

4 

D29 

O 

0,1 

0 

4 

Spare 

N/A 

0 

4 

3 

D30 

O 

0,1 

0 

3 

Spare 

N/A 

0 

4 

2 

D31 

O 

0,1 

0 

2 

Spare 

N/A 

0 

4 

i 

D32.1 

C 

0,1 

0 

i 

Spare 

N/A 

0 

4 

0 

D32.2 

C 

0,1 

0 

0 

Spare 

N/A 

0 

As  an  example,  an  Existence  Mask  in  which  the  first  2  bytes  transmitted  (bytes  7  and  6)  have 
hexadecimal  value  OxFF3F  is  inteipreted  to  mean  that  fields  D2  through  D9  and  D12  through 
D17  exist  and  are  transmitted  (as  indicated  by  binary  ones  in  those  fields).  Fields  DIO  and  Dll 
(corresponding  to  Fatitude  and  Fongitude  Scale  Factors)  do  not  exist  (as  indicated  by  binary 
zeroes)  and  are  not  transmitted.  Table  A- 16  shows  this  example  for  bytes  7  and  6  of  the  Existence 
Mask. 
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Table  A- 16.  Example  of  Existence  Mask 


Bvtc 

Bvte  7 

Bvte  6 

Hex 

F 

F 

3 

F 

Mask 

1 

i 

i 

i 

1 

i 

i 

i 

0 

0 

i 

i 

1 

i 

i 

l 

Field 

D2 

D3 

D4 

D5 

D6 

D7 

D8 

D9 

DIO 

Dll 

DI2 

D 1 3 

D 14 

D15 

D 16 

D17 

Xmit? 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

No 

No 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

A.5.2  Revisit  Index  (D2)  (M). 

The  sequential  count  of  a  revisit  of  the  bounding  area  for  a  given  job  ID. 

A  Revisit  Index  of  “0”  indicates  the  first  revisit. 

A.5.3  Dwell  Index  (D3)  (M). 

The  temporally  sequential  count  of  a  dwell  within  the  revisit  of  a  particular  bounding  area  for  a 
given  job  ID. 

A  dwell  index  of  “0”  indicates  the  first  dwell  of  the  revisit.  (NOTE:  Revisit  counts  are  allowed  to 
“wrap”  when  the  allowable  range  of  revisits  is  exceeded.) 

A.5.4  Last  Dwell  of  Revisit  (D4)  (M). 

A  flag  to  indicate  that  this  is  the  last  dwell  of  the  revisit. 

The  Last  Dwell  of  Revisit  flag  set  to  “1”  indicates  there  are  no  additional  dwells  within  that 
revisit.  (NOTE:  A  Dwell  Index,  field  D3,  of  “0”  and  a  Last  Dwell  of  Revisit,  field  D4,  of  “1” 
indicates  this  is  the  first  and  only  dwell.  This  allows  the  concept  of  a  “dwell”  to  be  used  by 
systems  that  do  not  utilize  multiple  dwells  or  revisits  of  the  radar  beam.) 

A.5.5  Target  Report  Count  (D5)  (M). 

A  count  of  the  total  number  of  targets  reported  during  this  dwell  and  sent  in  this  Dwell  Segment. 

A.5.6  Dwell  Time  (D6)  (M). 

The  elapsed  time,  expressed  in  milliseconds,  from  the  midnight  at  the  beginning  of  the  day 
specified  in  the  Reference  Time  fields  of  the  Mission  Segment  to  the  temporal  centre  of  the  dwell. 

In  this  manner,  the  Dwell  Time  corresponds  to  the  day's  UTC  time  converted  to  milliseconds, 
with  the  possible  addition  of  multiples  of  86400000  for  multi-day  missions. 


34 


DRDC  Ottawa  TM  2007-341 


A.5.7  Sensor  Position  -  Latitude  (D7)  (M). 


The  North-South  position  of  the  sensor  at  the  temporal  centre  of  the  dwell  expressed  as  degrees 
North  (positive)  or  South  (negative)  of  the  Equator. 

A.5.8  Sensor  Position  -  Longitude  (D8)  (M). 

The  East-West  position  of  the  sensor  at  the  temporal  centre  of  the  dwell,  expressed  as  degrees 
East  (positive)  from  the  Prime  Meridian. 

A.5.9  Sensor  Position  -  Altitude  (D9)  (M). 

The  altitude  of  the  sensor  at  temporal  centre  of  the  dwell,  referenced  to  its  position  above  the 
WGS  84  ellipsoid,  expressed  in  centimetres. 

A.5.10  Scale  Factor  -  Latitude  Scale  (DIO)  (C). 

A  factor  which  modifies  the  value  of  the  reported  target  latitude  (Delta  Latitude,  field  D32.4) 
when  it  is  necessary  to  send  the  reduced  bandwidth  version  of  the  Target  Report. 

The  Latitude  Scale  factor  and  Delta  Latitude  are  used  in  conjunction  with  the  Dwell  Area  Centre 
Latitude  (field  D24)  to  recover  the  target  latitude  as  follows: 

Latitude  =  [(Delta  Lat)  x  (Lat  Scale)]  +  (Centre  Lat)  =  [(D32.4)  x  (DIO)]  +  (D24) 

The  Latitude  Scale  shall  be  chosen  in  accordance  with  the  guidance  given  in  the  AEDP-7  for 
STANAG  4607. 

Field  D 1 0  is  Conditional  and  is  always  sent  with  field  Dll.  They  are  sent  if  and  only  if  the 
optional  difference  fields  Delta  Latitude  (D32.4)  and  Delta  Longitude  (D32.5)  are  sent  in  the 
Target  Report. 

A.5.11  Scale  Factor  -  Longitude  Scale  (Dll)  (C). 

A  factor  which  modifies  the  value  of  the  reported  target  longitude  (Delta  Longitude,  field  D32.5) 
when  it  is  necessary  to  send  the  reduced  bandwidth  version  of  the  Target  Report. 

The  Longitude  Scale  factor  and  Delta  Longitude  are  used  in  conjunction  with  the  Dwell  Area 
Centre  Longitude  (field  D25)  to  recover  the  target  latitude  as  follows: 

Longitude  =  [(Delta  Long)  x  (Long  Scale)]  +  (Centre  Long)  =  [(D32.5)  x  (Dll)]  +  (D25) 

The  Longitude  Scale  shall  be  chosen  in  accordance  with  the  guidance  given  in  the  AEDP-7  for 
STANAG  4607. 
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Field  Dll  is  Conditional  and  is  always  sent  with  field  DIO.  They  are  sent  if  and  only  if  the 
optional  difference  fields  Delta  Latitude  (D32.4)  and  Delta  Longitude  (D32.5)  are  sent  in  the 
Target  Report). 

A.5.12  Sensor  Position  Uncertainty  -  Along  Track  (D12)  (O). 

Estimate  of  the  standard  deviation  in  the  estimated  horizontal  sensor  location  at  the  time  of  the 
dwell,  measured  along  the  sensor  track  direction  (field  D15),  expressed  in  centimetres. 

Field  D12  is  Optional.  It  is  always  sent  with  fields  D13  and  D14. 

A.5.13  Sensor  Position  Uncertainty  -  Cross-Track  (D13)  (O). 

Estimate  of  the  standard  deviation  in  the  estimated  horizontal  sensor  location  at  the  time  of  the 
dwell  measured  orthogonal  to  the  track  direction  (field  D1 5),  expressed  in  centimetres. 

Field  D13  is  Optional.  It  is  always  sent  with  fields  D12  and  D14. 

A.5.14  Sensor  Position  Uncertainty  -  Altitude  (D14)  (O). 

Standard  deviation  of  the  sensor  altitude  estimate  (field  Dll),  expressed  in  centimetres. 

Field  D14  is  Optional.  It  is  always  sent  with  fields  D12  and  D13 

A.5.15  Sensor  Track  (D15)  (C). 

The  ground  track  of  the  sensor  at  the  time  of  the  dwell  expressed  as  the  angle  in  degrees 
(clockwise)  from  True  North. 

Field  D15  is  Conditional  and  is  always  sent  with  fields  D16  and  D17.  They  are  sent  only  when 
the  sensor  system  provides  these  parameters. 

A.5.16  Sensor  Speed  (D16)  (C). 

The  ground  speed  of  the  sensor  at  the  time  of  the  dwell,  expressed  as  millimetres  per  second. 

Field  D16  is  Conditional  and  is  always  sent  with  fields  D15  and  D17.  They  are  sent  only  when 
the  sensor  system  provides  these  parameters. 

A.5.17  Sensor  Vertical  Velocity  (D17)  (C). 

The  velocity  of  the  sensor  in  the  vertical  direction,  expressed  as  decimetres  per  second. 

Field  D17  is  Conditional  and  is  always  sent  with  fields  D15  and  D16.  They  are  sent  only  when 
the  sensor  system  provides  these  parameters. 
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A.5.18  Sensor  Track  Uncertainty  (D18)  (O). 

The  standard  deviation  of  the  estimate  of  the  sensor  track  along  the  ground,  expressed  in  degrees. 
Field  D18  is  Optional.  It  is  always  sent  with  fields  D19  and  D20. 


A.5.19  Sensor  Speed  Uncertainty  (D19)  (O). 

The  standard  deviation  of  estimate  of  the  sensor  speed,  expressed  in  millimetres  per  second. 

Field  D19  is  Optional.  It  is  always  sent  with  fields  D18  and  D20. 

A.5.20  Sensor  Vertical  Velocity  Uncertainty  (D20)  (O). 

The  standard  deviation  of  estimate  of  the  sensor  vertical  velocity,  expressed  in  centimetres  per 
second. 

Field  D20  is  Optional.  It  is  always  sent  with  fields  D18  and  D19. 

A.5.21  Platform  Orientation  -  Heading  (D21)  (C). 

The  heading  of  the  platform  at  the  time  of  the  dwell,  expressed  as  the  angle  in  degrees  (clockwise) 
from  True  North  to  the  roll  axis  of  the  platform,  where  roll  axis  is  defined  in  Figure  A-l. 

Field  D21  is  Conditional  and  is  always  sent  with  fields  D22  and  D23.  They  are  sent  only  when 
the  platform  provides  these  parameters. 
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+  Pitch 
(2nd  Rotation) 


+  m 

(3d  Rotation) 


+  Heading 
(Is  Rotation) 


Roll  Axis 


Yaw  Axis 

Figure  A-l .  Platform  Orientation  Axes  (from  [4])  (order  of  rotations:  heading,  then  pitch,  then 

roll) 


Pitch  Axis 


+  Pitch 


A.5.22  Platform  Orientation  -  Pitch  (D22)  (C). 

The  pitch  angle  of  the  platform  at  the  time  of  the  dwell,  expressed  as  the  angle  in  degrees  of  the 
rotation  of  the  platform  about  its  pitch  axis,  as  shown  Figure  A-l,  where  a  positive  angle  is  an 
upward  attitude  of  the  nose  of  the  platform. 

Field  D22  is  Conditional  and  is  always  sent  with  fields  D21  and  D23.  They  are  sent  only  when 
the  platform  provides  these  parameters. 

A.5.23  Platform  Orientation  -  Roll  (D23)  (C). 

The  roll  angle  of  the  platform  at  the  time  of  the  dwell,  expressed  as  the  angle  in  degrees  of  the 
rotation  of  the  platform  about  its  roll  axis,  as  shown  in  Figure  A-l,  where  a  positive  angle  is  the 
clockwise  direction  as  viewed  from  the  rear  of  the  platform.  (NOTE:  The  term  “Platform  Bank 
Angle’’  is  synonymous  with  the  term  “Platform  Roll  Angle”.) 

Field  D23  is  Conditional  and  is  always  sent  with  fields  D21  and  D22.  They  are  sent  only  when 
the  platform  provides  these  parameters. 


38 


DRDC  Ottawa  TM  2007-341 


A.5.24  Dwell  Area  -  Centre  Latitude  (D24)  (M). 

The  North-South  position  of  the  centre  of  the  dwell  area,  expressed  as  degrees  North  (positive)  or 
South  (negative)  of  the  Equator. 

A.5.25  Dwell  Area  -  Centre  Longitude  (D25)  (M). 

The  East-West  position  of  the  centre  of  the  dwell  area,  expressed  as  degrees  East  (positive)  of  the 
Prime  Meridian. 

A.5.26  Dwell  Area  -  Range  Half  Extent  (D26)  (M). 

The  distance  on  the  earth  surface,  expressed  in  kilometres,  from  the  near  edge  to  the  centre  of  the 
dwell  area. 

A.5.27  Dwell  Area  -  Dwell  Angle  Half  Extent  (D27)  (M). 

For  dwell  based  radars,  one-half  of  the  3-dB  beamwidth,  expressed  in  degrees  as  a  16-bit 
unsigned  binary >  angle.  For  non-dwell  based  radars,  the  angle  between  the  beginning  of  the  dwell 
to  the  centre  of  the  dwell,  as  measured  from  the  sensor’s  position 

A.5.28  Sensor  Orientation  -  Heading  (D28)  (O). 

The  rotation  of  the  sensor  broadside  face  about  the  local  vertical  axis  of  the  platform,  expressed 
in  degrees  clockwise  when  viewed  from  above. 

This  is  the  first  of  three  successive  rotations  from  a  hypothetical  initial  position  in  which  the 
sensor  broadside  (normal  to  the  sensor  face)  is  in  its  normal  “rest”  position  (i.e.,  along  the 
platform  roll  axis  for  forward-looking  sensors  or  along  the  platform  pitch  axis  for  side-looking 
sensors)  and  the  sensor  face  is  nominally  level  (i.e.,  the  lateral  axis  of  the  face  is  level,  pointing 
along  the  roll  or  pitch  axis  as  applicable,  and  the  yaw  axis  points  along  the  direction  of  the  local 
vertical).  In  the  case  where  the  sensor  is  an  electronically  steerable  array  (ESA),  ‘Sensor 
Orientation  -  Heading’  refers  to  the  rotation  of  the  radar  beam  about  the  local  vertical  axis  of  the 
platform,  and  is  independent  of  any  mechanical  rotation  of  the  sensor. 

Field  D28  is  optional.  If  at  least  one  of  fields  D28,  D29,  or  D30  is  present,  then  any  omitted  field 
shall  represent  an  angle  of  zero  degrees. 

A.5.29  Sensor  Orientation  -  Pitch  (D29)  (O). 

The  rotation  angle  of  the  sensor  normal  about  the  lateral  axis  of  the  sensor  broadside,  which  is 
pointing  in  the  direction  defined  by  the  sensor  orientation  heading  angle.  It  is  expressed  in 
degrees,  where  an  angle  above  the  horizontal  is  positive. 

This  is  the  second  of  three  successive  rotations  from  the  hypothetical  initial  position  of  the  sensor, 
as  described  above.  In  the  case  where  the  sensor  is  an  electronically  steerable  array  (ESA), 
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'Sensor  Orientation  -  Pitch'  refers  to  the  rotation  of  the  radar  beam  about  the  lateral  axis  of  the 
platform,  and  is  independent  of  any  mechanical  rotation  of  the  sensor. 

Field  D29  is  Optional.  If  at  least  one  of  the  fields  D28,  D29,  or  D30  is  present,  then  any  omitted 
field  shall  represent  an  angle  of  zero  degrees. 

A.5.30  Sensor  Orientation  -  Roll  (D29)  (O). 

The  rotation  angle  of  the  sensor  about  the  transverse  axis  of  the  sensor  broadside,  which  is 
pointing  in  the  direction  defined  by  the  sensor  orientation  heading  angle.  It  is  expressed  in 
degrees,  where  a  clockwise  location  is  positive,  as  seen  from  behind  the  face  of  the  sensor. 

This  is  the  third  of  three  successive  rotations  from  the  hypothetical  initial  position  of  the  sensor, 
as  described  above.  In  the  case  where  the  sensor  is  an  electronically  steerable  array  (ESA), 
'Sensor  Orientation  -  Roll'  refers  to  the  rotation  of  the  radar  beam  about  the  transverse  axis  of  the 
platform,  and  is  independent  of  any  mechanical  rotation  of  the  sensor. 

Field  D30  is  Optional.  If  at  least  one  of  the  fields  D28,  D29,  or  D30  is  present,  then  any  omitted 
field  shall  represent  an  angle  of  zero  degrees. 

A.5.31  Minimum  Detectable  Velocity,  MDV  (D31)  (O). 

The  minimum  velocity  component,  long  the  line  of  sight,  which  can  be  detected  by  the  sensor; 
expressed  in  decimetres  per  second. 

Field  D3 1  is  optional. 

A.5.32  <Target  Reports>. 

Table  A- 17  describes  the  format  for  the  Target  Reports.  One  target  report  shall  be  transmitted  for 
each  target  observed  within  the  dwell.  Targets  detected  within  a  dwell  may  be  split  among 
multiple  Dwell  Segments.  Targets  detected  within  a  dwell,  but  by  different  radar  modes  or  radar 
processors  shall  be  reported  in  separate  dwell  segments.  Table  A-ll  provides  a  list  of  radar 
modes. 
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Table  A- 17.  Target  Report 


Field 

Type 

Field  Name 

Bytes 

Form 

Value 

Units 

D32.1 

C 

MTI  Report  Inc 

ex 

2 

116 

0  to  65535 

D32.2 

C 

Target 

Location 

Latitude 

4 

SA32 

-  90  to  +89.999989 

degrees 

D32.3 

c 

Longitude 

4 

BA32 

0  to +359.999999916 

degrees 

D32.4 

c 

Delta  Lat 

2 

S16 

-  32768  to  +32767 

D32.5 

c 

Delta  Long 

2 

S16 

-  32768  to  +32767 

D32.6 

0 

Geo  Height 

2 

S16 

-  1000  to  +  10000 

metres 

D32.7 

0 

V  radial 

2 

S  16 

-32768  to  +32767 

centimetres/sec 

D32.8 

0 

Wrap  Velocity 

2 

116 

0  to  65535 

centimetres/sec 

D32.9 

0 

Target  SNR 

1 

S8 

-128  to +127 

dB 

D32.10 

0 

Target  classification 

1 

E8 

Table  A- 18 

D32.ll 

0 

Target  class,  probability 

1 

18 

0  to  100 

percent 

D32.12 

c 

Target 

measurement  SD 

Slant  range 

2 

116 

0  to  65535 

centimetres 

D32.13 

c 

Cross  range 

2 

116 

0  to  65535 

decimetres 

D32.14 

c 

Height 

1 

18 

0  to  255 

metres 

D32.15 

c 

V  RADIAL 

2 

116 

0  to  5000 

centimetres/sec 

D32.16 

c 

Truth  Tag 

Application 

1 

18 

0,  1  to  255 

0,  1  to  4294967295 

D32.17 

c 

Entity 

4 

132 

A.5.32.1  MTI  Report  Index  (D32.1)  (C). 

The  sequential  count  of  this  MTI  report  within  the  dwell. 

Field  D32.1  is  Conditional  and  must  be  sent  if  an  HRR  report  is  provided  for  targets  in  this  dwell. 

A.5.32.2 Target  Location  -  High-Resolution  Latitude  (D32.2)  (C). 

The  North-South  position  of  the  reported  detection,  expressed  as  degrees  North  (positive)  or 
South  (negative)  of  the  Equator. 

Field  D32.2  is  Conditional  and  is  always  sent  with  field  D32.3.  They  are  sent  only  when  the 
transmission  bandwidth  permits  the  use  of  4  bytes  each  for  target  latitude  and  longitude.  If  fields 
D32.2  and  D32.3  are  sent,  then  fields  D32.4  and  D32.5  are  not  sent. 

A.5.32.3 Target  Location  -  High-Resolution  Longitude  (D32.3)  (C). 

The  East-West  position  of  the  reported  detection,  expressed  as  degrees  East  (positive)  of  the 
Prime  Meridian. 

Field  D32.2  is  Conditional  and  is  always  sent  with  field  D32.3.  They  are  sent  only  when  the 
transmission  bandwidth  permits  the  use  of  4  bytes  each  for  target  latitude  and  longitude.  If  fields 
D32.2  and  D32.3  are  sent,  then  fields  D32.4  and  D32.5  are  not  sent. 
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A.5.32.4 Target  Location  -  Delta  Latitude  (D32.4)  (C). 


The  North-South  position  of  the  reported  detection,  expressed  as  degrees  North  (positive)  or 
South  (negative)  from  the  Dwell  Area  Centre  Latitude  (the  Reference  Point)  sent  in  Field  D24. 

The  field  shall  be  sent  when  it  is  necessary  to  send  the  reduced  bandwidth  version  of  the  Target 
Report.  Delta  Latitude  is  used  in  conjunction  with  the  Latitude  Scale  factor  (field  DIO)  and  the 
Dwell  Area  Centre  Latitude  (field  D24)  to  recover  the  target  latitude  as  follows: 

Latitude  =  [(Delta  Lat)  x  (Lat  Scale)]  +  (Centre  Lat)  =  [(D32.4)  x  (DIO)]  +  (D24) 

Field  D32.4  is  Conditional  and  is  always  sent  with  fields  D32.5,  DIO,  and  Dll.  They  shall  be 
used  when  the  transmission  bandwidth  and  the  number  of  targets  do  not  permit  the  use  of  4  bytes 
each  for  target  latitude  and  longitude.  If  fields  D32.4,  D32.5,  DIO,  and  Dll  are  sent,  then  fields 
D32.2  and  D32.3  are  not  sent. 


A.5.32.5 Target  Location  -  Delta  Longitude  (D32.5)  (C). 

The  East-West  position  of  the  reported  detection,  expressed  as  degrees  East  (positive)  from  the 
Dwell  Area  Centre  Longitude  (the  Reference  Point)  sent  in  Field  D25. 

The  field  shall  be  sent  when  it  is  necessary  to  send  the  reduced  bandwidth  version  of  the  Target 
Report.  Delta  Longitude  is  used  in  conjunction  with  the  Longitude  Scale  factor  (field  Dll)  and 
the  Dwell  Area  Centre  Longitude  (field  D25)  to  recover  the  target  longitude  as  follows: 

Longitude  =  [(Delta  Lon)  x  (Lon  Scale)]  +  (Centre  Lon)  =  [(D32.5)  x  (Dll)]  +  (D25) 

Field  D32.4  is  Conditional  and  is  always  sent  with  fields  D32.5,  DIO,  and  Dll.  They  shall  be 
used  when  the  transmission  bandwidth  and  the  number  of  targets  do  not  permit  the  use  of  4  bytes 
each  for  target  latitude  and  longitude.  If  fields  D32.4,  D32.5,  DIO,  and  Dll  are  sent,  then  fields 
D32.2  and  D32.3  are  not  sent. 

A.5.32.6 Target  Location  -  Geodetic  Height  (D32.6)  (O). 

This  field  reports  the  geodetic  height  used  within  the  translation  from  the  target ’s  radar 
coordinates  to  the  target ’s  geodetic  coordinates. 

If  the  geoid  model  flag  (J28)  is  set,  the  height  shall  be  interpreted  as  an  orthometric  height  (i.e. 
height  above  mean  sea  level).  If  J28  is  not  set,  the  height  shall  be  inteipreted  as  a  height  above  the 
WGS84  ellipsoid  (HAE),  whether  or  not  an  elevation  model  (field  J27)  has  been  used.  If  fields 
J27  and/or  J28  are  not  set,  elevation  or  geoid  data  may  also  be  available  from  alternative  local 
sources,  such  as  the  lOo  x  lOo  geoid  height  data  over  the  WGS84  ellipsoid,  with  DTED  Level  0 
terrain  elevation  data,  which  is  available  over  the  Internet.  Field  D32.6  is  Optional. 
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A.5.32.7 Target  Velocity  Line-Of-Sight  Component  (D32.7)  (O). 


The  component  of  velocity  for  the  reported  detection,  expressed  in  centimetres  per  second, 
corrected  for  platform  motion,  along  the  line  of  sight  between  the  sensor  and  the  reported 
detection,  where  the  positive  direction  is  away  from  the  sensor.  It  may  also  be  known  as  the 
Radial  Velocity. 

Field  D32.7  is  Optional.  If  field  D32.7  is  sent,  then  field  D32.8  shall  also  be  sent. 


A.5.32.8 Target  Wrap  Velocity  (D32.8)  (O). 

Half  the  velocity  aliasing  period. 

For  most  radars  this  is  calculable  as  the  effective  PRF  (i.e.,  the  product  of  PRF's  on  CPI's  for 
which  the  target  was  detected)  multiplied  by  the  effective  sensor  wavelength  divided  by  four.  The 
target  wrap  velocity  permits  trackers  to  un-wrap  velocities  for  targets  with  line-of  sight 
components  large  enough  to  exceed  the  first  velocity  period.  When  the  target's  wrap  velocity  is 
low  compared  to  the  target's  expected  line-of-sight  velocity  the  tracker  may  consider  adding 
multiples  of  twice  the  target  wrap  velocity  to  field  D32.7. 

Field  D32.8  is  Optional.  If  field  D32.8  is  sent,  then  field  D32.7  shall  also  be  sent. 

A.5.32.9 Target  SNR  (D32.9)  (O). 

Estimated  Signal  to  Noise  ratio  (SNR)  of  the  target  return,  expressed  in  decibels. 

Field  D32.9  is  optional. 


A.5.32.10  Target  Classification  (D32.10)  (O). 

An  enumeration  field  denoting  the  classification  of  the  target. 

Classification  types  shall  include  wheeled,  non-wheeled  (i.e.  tracked),  helicopter,  low-slow  flyer, 
rotating  antenna,  maritime,  beacon,  and  unknown,  for  both  live  and  simulated  targets.  If  a  target 
cannot  be  classified,  it  shall  be  marked  as  “unknown”.  The  enumeration  table  for  target 
classification  is  shown  in  Table  A- 18 

Field  D32.10  is  optional. 
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Table  A- 18.  Target  Classification 


VALUE 

TARGET  CLASSIFICATION 

0 

No  Infomiation,  Live  Target 

1 

Tracked  Vehicle.  Live  Target 

2 

Wheeled  Vehicle,  Live  Target 

3 

Rotary  Wing  Aircraft,  Live  Target 

4 

Fixed  Wing  Aircraft,  Live  Target 

5 

Stationary  Rotator,  Live  Target 

6 

Maritime,  Live  Target 

*7 

Beacon,  Live  Target 

8 

Amphibious,  Live  Target 

9-125 

Reserved 

126 

Other,  Live  Target 

127 

Unknown,  Live  Target 

128 

No  Information,  Simulated  Target 

129 

Tracked  Vehicle,  Simulated  Target 

130 

Wheeled  Vehicle,  Simulated  Target 

131 

Rotary  Wing  Aircraft,  Simulated  Target 

132 

Fixed  Wing  Aircraft,  Simulated  Target 

133 

Stationary  Rotator,  Simulated  Target 

134 

Maritime,  Simulated  Target 

135 

Beacon,  Simulated  Target 

136 

Amphibious,  Simulated  Target 

137-253 

Reserved 

254 

Other,  Simulated  Target 

255 

Unknown,  Simulated  Target 

A.5.32.11  Target  Classification  Probability  (D32.11)  (O). 

The  estimated  probability  that  the  target  classification  appearing  in  field  D32.10  is  correctly 
classified. 

Field  D32.1 1  is  Optional. 

A.5.32.12  Target  Measurement  Uncertainty  -  Slant  Range  (D32.12)  (C). 

The  standard  deviation  of  the  estimated  slant  range  of  the  reported  detection,  expressed  in 
centimetres. 

Field  D32.12  is  conditional.  It  is  sent  only  if  fields  12  is  C  D12,  D13,  and  D14  of  the  Dwell 
Segment  are  sent,  and  shall  be  sent  with  fields  D32.13,  D32.14,  and  DD32.15,  if  they  are 
available. 
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A.5.32.13  Target  Measurement  Uncertainty  -  Cross  Range  (D32.13)  (C). 


The  standard  deviation  of  the  position  estimate,  in  the  cross-range  direction,  of  the  reported 
detection,  expressed  in  decimetres. 

Field  D32.13  is  Conditional.  It  is  sent  only  if  fields  D12,  D13,  and  D14  of  the  Dwell  Segment  are 
sent,  and  shall  be  sent  with  fields  D32.12,  D32.14,  and  D32.15,  if  they  are  available. 

A.5.32.14  Target  Measurement  Uncertainty  -  Height  (D32.14)  (C). 

The  standard  deviation  of  the  estimated  geodetic  height  reported  in  field  D32.6,  expressed  in 
metres. 

Field  D32.14  is  conditional.  It  is  sent  only  if  fields  D12,  D13,  and  D14  of  the  Dwell  Segment  and 
D32.7  of  the  Target  Report  are  sent,  and  shall  be  sent  with  fields  D32.12,  D32.13,  and  D32.15,  if 
they  are  available. 

A.5.32.15  Target  Measurement  Uncertainty  -Target  Radial  Velocity  (D32.15) 

(C !L 

The  standard  deviation  of  the  measured  line-of-sight  velocity  component  reported  in  field  D32. 7, 
expressed  in  centimetres  per  second. 

Field  D32.15  is  conditional.  It  is  sent  only  if  fields  D12,  D13,  and  D14  of  the  Dwell  Segment  and 
D32.7  of  the  Target  Report  are  sent,  and  shall  be  sent  with  fields  D32.12,  D32.13,  and  D32.14,  if 
they  are  available. 


A.5.32.16  Truth  Tag  -  Application  (D32.16)  (C). 

The  Truth  Tag  -  Application  is  the  Application  Field,  truncated  to  8  bits,  from  the  Entity  State 
Protocol  Data  Unit  (PDU)  used  to  generate  the  MTI  Target.  If  the  MTI  target  is  the  result  of 
more  than  one  Entity  State  PDU,  then  the  value  of  the  target  with  the  highest  instantaneous  radar 
return  is  passed  in  this  field. 

A  value  of  all  zeroes  indicates  that  no  information  is  available  regarding  the  Entity  State  PDU 
that  was  used  to  generate  the  MTI  Target  being  passed.  For  simulated  data,  the  Truth  Tag  relates 
targets  back  to  the  truth  data,  which  is  represented  using  Distributed  Interactive  Simulation  (DIS 
Entity  State  PDUs). 

Field  D32.16  is  Conditional  and  is  sent  only  if  the  MTI  Target  in  this  Report  is  simulated.  It  is 
always  sent  with  field  D32.17. 


A.5.32.17  Truth  Tag  -  Entity  (D32.17)  (C). 

The  Truth  Tag  -  Entity  is  the  Entity  Field  from  the  Entity  State  PDU  used  to  generate  the  MTI 
Target.  It  is  passed  as  a  32-bit  value,  in  the  same  format  as  the  Entity  State  PDU  Identity  value. 
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A  value  of  all  zeros  indicates  that  no  information  is  available  regarding  the  Entity  State  PDU  that 
was  used  to  generate  the  MTI  Target  being  passed.  For  simulated  data,  the  Truth  Tag  relates 
targets  back  to  the  truth  data,  which  is  represented  using  Distributed  Interactive  Simulation  (DIS 
Entity  State  PDUs). 

Field  D32.17  is  Conditional  and  is  sent  only  if  the  MTI  Target  in  this  Report  is  simulated.  It  is 
always  sent  with  field  D32.16. 

A.6  Platform  Location  Segment 

The  Platform  Location  Segment  (Table  A- 19)  provides  information  pertaining  to  the  location  of 
the  sensor  platform  during  periods  when  the  sensor  is  not  collecting  data.  It  shall  be  sent  as 
required  during  periods  in  which  the  sensor  is  not  collecting  data,  such  as  enroute  to  an  orbit 
location  or  during  a  turn. 


Table  A- 19.  Platform  Location  Segment 


Field 

Type 

Field  name 

Bytes 

Form 

Values 

Units 

LI 

M 

Location  Time 

4 

132 

0  to  4  x  1 0E9 

milliseconds 

L2 

M 

Platform 

position 

Latitude 

4 

SA32 

-  90  to  +89.9999999 

0  to  +359.9999999 
-10000  to  +8000000 

degrees 

degrees 

decimetres 

L3 

M 

Longitude 

4 

BA32 

L4 

M 

Altitude 

4 

S32 

L5 

M 

Platform  track 

2 

BA16 

0  to  359.9945 

degrees 

L6 

M 

Platform  Speed 

4 

132 

0  to  8000000 

millimetres/sec 

L7 

M 

Platform  Vertical  Velocity 

1 

S8 

-128  to +127 

millimetres/sec 

A.6.1  Location  Time  (LI)  (M). 

The  elapsed  time,  expressed  in  milliseconds,  from  midnight  at  the  beginning  of  the  day  specified 
in  the  Reference  Time  fields  of  the  Mission  Segment  to  the  time  the  report  is  prepared. 

In  this  manner,  the  Location  Time  corresponds  to  the  day's  UTC  time  converted  to  milliseconds, 
with  the  possible  addition  of  multiples  of  86400000  for  multi-day  missions. 

A.6.2  Platform  Position  -  Latitude  (L2)  (M). 

The  North-South  position  of  the  platform  at  the  time  the  report  is  prepared,  expressed  as  degrees 
North  (positive)  or  South  (negative)  of  the  Equator. 

A.6. 3  Platform  Position  -  Longitude  (L3)  (M). 

The  East-  West  position  of  the  platform  at  the  time  the  report  is  prepared,  expressed  as  degrees 
East  (positive)  from  the  Prime  Meridian. 
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Platform  Position  -  Altitude  (L4)  (M). 

The  altitude  of  the  platform  at  the  time  the  report  is  prepared,  referenced  to  its  position  above  the 
WGS  84  ellipsoid,  expressed  in  centimetres. 


A.6.5  Platform  Track 


The  ground  track  of  the  platform  at  the  time  at  the  time  the  report  is  prepared,  expressed  as  the 
angle  in  degrees  (clockwise)  from  True  North. 


A.6.6  Platform  Speed 


The  ground  speed  of  the  platform  at  the  time  at  the  time  the  report  is  prepared,  expressed  in 
millimetres  per  second. 


A.6.7  Platform  Vertical  Velocity 


The  velocity  of  the  platform  in  the  vertical  direction,  expressed  as  decimetres  per  second. 
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Annex  B  Compendium  of  Proposed  STANAG  4607 
_ Segment  Extensions _ 


This  section  provides  tables  and  descriptions  of  the  proposed  new  extensions  for  use  with  the  core 
set  of  Headers  and  Segments  identified  in  Annex  A.  These  extensions  and  the  base  segments  they 
are  attached  to  (described  in  Annex  A)  form  the  segment  set  that  will  be  implemented  by  DR  DC 
in  support  of  RADARSAT-2  GMTI  data.  In  the  following  tables,  entries  in  blue  indicate 
quantities  which  will  always  be  reported  by  RADARSAT-2  GMTI,  those  in  green  indicate 
quantities  which  can  be  provided  depending  on  the  users’  needs  and  bandwidth  considerations, 
while  those  in  red  will  not  be  implemented  by  RADARSAT-2  GMTI. 

B.1  Advanced  Dwell  Segment  Extension 

An  Advanced  Dwell  Segment  Extension  is  a  report  on  a  grouping  of  zero  or  more  target  reports 
for  which  the  sensor  provides  a  single  time,  sensor  position,  reference  position  on  the  ground  with 
simple  estimates  for  the  observed  area  at  the  reported  time,  and  other  pertinent  data.  An 
Advanced  Dwell  Segment  Extension  may  be  associated  with  a  radar  dwell  but  need  not  be.  The 
Advanced  Dwell  Segment  Extension  (Table  B-l)  presents  data  pertinent  to  GMTI  targets  detected 
by  GMTI  sensors,  including  airborne  and  spacebome  sensors.  Dwell  Segments  shall  be  sent  for 
each  logical  grouping  of  target  reports,  and  an  Advanced  Dwell  Segment  Extension  may 
optionally  be  sent  for  each  dwell  segment.  An  Advanced  Dwell  Segment  Extension  may 
optionally  be  transmitted,  in  conjunction  with  a  Dwell  Segment,  if  no  targets  are  observed. 
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Table  B-l.  Advanced  Dwell  Segment  Extension 


Field 

Type 

Field  Name 

Bytes 

Form 

Value  Range 

Units 

ADI 

M 

Existence  Mask 

8 

FL64 

Table  B-2 

AD2 

M 

Revisit  Index 

2 

116 

0  to  65535 

AD3 

M 

Dwell  Index 

2 

116 

0  to  65535 

AD4 

O 

Dwell  minimum  range 

4 

132 

0  to  4294967295 

centimetres 

AD5 

C 

Reference  Coordinate  System 

1 

E8 

Per  para.  4.1.5 

AD6 

o 

Slant-Range  sample  Spacing 

2 

116 

0  to  65535 

centimetres 

AD  7 

o 

Cross-Range  Sample  Spacing 

2 

116 

0  to  65535 

centimetres 

AD8 

o 

Slant-Range  Resolution 

2 

116 

0  to  65535 

centimetres 

AD9 

o 

Cross-Range  Resolution 

2 

116 

0  to  65535 

centimetres 

AD  10 

c 

Platform 

Position 

X 

8 

S64 

(-2W)  to  (26J  -  1) 

millimetres 

ADI  1 

c 

Y 

8 

S64 

(-2W)  to  (26J  -  1) 

millimetres 

AD12 

c 

Z 

8 

S64 

(-2W)  to  (26J  -  1) 

millimetres 

AD  13 

o 

Platform 
Position 
Uncertainty 
(one  standard 
deviation) 

X 

4 

132 

0  to  4294967295 

millimetres 

ADM 

o 

Y 

4 

132 

0  to  4294967295 

millimetres 

AD  15 

o 

Z 

4 

132 

0  to  4294967295 

millimetres 

AD  16 

c 

Platform 

Velocity 

X-Prime 

4 

S32 

-2147483648  to 
2147483647 

millimetres/sec 

AD  17 

c 

Y-  Prime 

4 

S32 

-2147483648  to 
2147483647 

millimetres/sec 

AD  18 

c 

Z-  Prime 

4 

S32 

-2147483648  to 
2147483647 

millimetres/sec 

AD  19 

o 

Platform 

Velocity 

Uncertainty 

X-Prime 

2 

116 

0  to  65535 

millimetres/sec 

AD20 

o 

Y-  Prime 

2 

116 

0  to  65535 

millimetres/sec 

AD21 

o 

Z-  Prime 

2 

116 

0  to  65535 

millimetres/sec 

AD22 

c 

High 

Resolution 

Platform 

Orientation 

Yaw 

4 

BA32 

0  to  +359.999979 

degrees 

AD23 

c 

Pitch 

4 

BA32 

0  to  +359.999979 

degrees 

AD24 

c 

Roll 

4 

BA32 

0  to  +359.999979 

degrees 

AD25 

o 

Sensor 

Position 

Vector 

X 

4 

S32 

-2147483648  to 
2147483647 

millimetres 

AD26 

o 

Y 

4 

S32 

-2147483648  to 
2147483647 

millimetres 

AD27 

o 

Z 

4 

S32 

-2147483648  to 
2147483647 

millimetres 

AD28 

o 

High 

Resolution 

Sensor 

Orientation 

Yaw 

4 

BA32 

0  to  +359.999979 

degrees 

AD29 

o 

Pitch 

4 

BA32 

0  to  +359.999979 

degrees 

AD30 

o 

Roll 

4 

BA32 

0  to  +359.999979 

degrees 

AD31 

o 

Dwell  Area  Centre  Elevation 

2 

S16 

-1000  to  10000 

metres 

AD32 

<  Advanced  Target  Report 
Extensions  > 

See  Table  4-1.2 
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B.1.1 


Existence  Mask  (ADI)  (M). 


The  Existence  Mask,  the  first  field  of  the  Advanced  Dwell  Segment  Extension,  is  an  encoded 
eight-byte  field  that  immediately  follows  the  Segment  Header  fields  and  precedes  all  other 
Advanced  Dwell  Segment  Extension  fields.  Each  field  of  the  Advanced  Dwell  Segment  Extension, 
with  the  exception  of  the  Existence  Mask  itself,  is  represented  by  a  reserved  bit  within  the 
Existence  Mask.  Each  bit  of  the  Existence  Mask  indicates  whether  or  not  the  corresponding  field 
of  the  Dwell  Segment  is  present  in  the  data  stream. 


The  most-significant  bit  (bit  7)  of  the  high-order  byte  (byte  7)  corresponds  to  the  first  field  (AD2) 
following  the  Existence  Mask  of  the  Advanced  Dwell  Segment  Extension,  where  the  high-order 
byte  shall  be  transmitted  first.  Figure  4-1  illustrates  the  mapping  of  each  Advanced  Dwell 
Segment  Extension  field  to  the  corresponding  bit  position  in  the  8-byte  Existence  Mask.  A  binary 
level  of  “1”  for  a  given  bit  indicates  that  the  corresponding  field  of  the  Advanced  Dwell  Segment 
Extension  is  present  in  the  data  stream  and  a  binary  level  of  “0”  indicates  that  it  is  not  present. 
Unused  bits  shall  be  filled  with  zeroes. 
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Table  B-2.  Advanced  Dwell  Segment  Extension  Existence  Mask  Mapping 


Byte 

No. 

Bit 

No. 

Field  No. 

Type 

Value 

Byte 

No. 

Bit 

No. 

Field  No. 

Type 

Value 

7 

7 

AD2 

M 

1 

3 

7 

AD32.3 

O 

0,1 

7 

6 

AD3 

M 

1 

3 

6 

AD32.4 

O 

0,1 

7 

5 

AD4 

O 

1 

3 

5 

AD32.5 

o 

0,1 

7 

4 

AD5 

C 

0,1 

3 

4 

AD32.6 

o 

0,1 

7 

3 

AD6 

O 

0,1 

3 

3 

AD32.7 

o 

0,1 

7 

2 

AD  7 

O 

0,1 

3 

2 

AD32.8 

o 

0,1 

7 

1 

AD  8 

O 

0,1 

3 

1 

AD32.9 

o 

0,1 

7 

0 

AD9 

O 

0,1 

3 

0 

AD32.10 

o 

0,1 

6 

7 

AD  10 

C 

0,1 

2 

7 

AD32.11 

o 

0,1 

6 

6 

ADI  1 

c 

0,1 

2 

6 

AD32.12 

o 

0,1 

6 

5 

AD  12 

c 

0,1 

2 

5 

AD32.13 

c 

0,1 

6 

4 

AD  13 

o 

0,1 

2 

4 

AD32.14 

c 

0,1 

6 

3 

ADM 

o 

0,1 

2 

3 

AD32.15 

c 

0,1 

6 

2 

AD  15 

o 

0,1 

2 

2 

AD32.16 

c 

0,1 

6 

1 

AD  16 

c 

0,1 

2 

1 

AD32.17 

c 

0,1 

6 

0 

AD  17 

c 

0,1 

2 

0 

AD32.18 

c 

0,1 

5 

7 

AD  18 

c 

0,1 

1 

7 

Spare 

N/A 

0 

5 

6 

AD  19 

o 

0,1 

1 

6 

Spare 

N/A 

0 

5 

5 

AD20 

o 

0,1 

1 

5 

Spare 

N/A 

0 

5 

4 

AD21 

o 

0,1 

1 

4 

Spare 

N/A 

0 

5 

3 

AD22 

c 

0,1 

1 

3 

Spare 

N/A 

0 

5 

2 

AD23 

c 

0,1 

1 

2 

Spare 

N/A 

0 

5 

1 

AD24 

c 

0,1 

1 

1 

Spare 

N/A 

0 

5 

0 

AD25 

o 

0,1 

1 

0 

Spare 

N/A 

0 

4 

7 

AD26 

o 

0,1 

0 

7 

Spare 

N/A 

0 

4 

6 

AD27 

o 

0,1 

0 

6 

Spare 

N/A 

0 

4 

5 

AD28 

o 

0,1 

0 

5 

Spare 

N/A 

0 

4 

4 

AD29 

o 

0,1 

0 

4 

Spare 

N/A 

0 

4 

3 

AD30 

o 

0,1 

0 

3 

Spare 

N/A 

0 

4 

2 

AD31 

o 

0,1 

0 

2 

Spare 

N/A 

0 

4 

1 

AD32.1 

M 

1 

0 

1 

Spare 

N/A 

0 

4 

0 

AD32.2 

o 

0,1 

0 

0 

Spare 

N/A 

0 

B.1.2  Revisit  Index  (AD2)  (M). 


The  sequential  count  of  a  revisit  of  the  bounding  area  for  a  given  job  ID,  where  a  Revisit  Index  of 
“0”  indicates  the  first  revisit. 

The  Revisit  Index  provides  linkage  between  the  Advanced  Dwell  Segment  Extension  and  the 
baseline  Dwell  Segment,  and  must  be  the  same  as  the  Revisit  Index  of  the  baseline  Dwell 
Segment. 
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B.1.3  Dwell  Index  (AD3)  (M). 


The  temporally  sequential  count  of  a  dwell  within  the  revisit  of  a  particular  bounding  area  for  a 
given  job  ID. 

A  dwell  index  of  “0”  indicates  the  first  dwell  of  the  revisit.  (NOTE:  Revisit  counts  are  allowed  to 
“wrap”  when  the  allowable  range  of  revisits  is  exceeded.)  The  Dwell  Index  provides  linkage 
between  the  Advanced  Dwell  Segment  Extension  and  the  baseline  Dwell  Segment,  and  must  be 
the  same  as  the  Dwell  Index  of  the  baseline  Dwell  Segment. 


B.1.4  Dwell  minimum  range  (AD4)  (O). 


The  minimum  measured  range  for  this  dwell,  expressed  in  centimetres  (i.e.  the  range  to  the  first 
pixel  in  the  swath). 

B.1.5  Reference  Coordinate  System  (AD5)  (C). 

An  enumeration  table  that  identifies  the  reference  coordinate  system  for  the  platform.  Coordinate 
systems  are  listed  in  Table  B-3. 

Field  AD5  is  Conditional  and  is  always  sent  with  Sensor  Position  fields  (AD  10,  ADI  1,  and 
AD12),  Sensor  Velocity  (AD16,  AD17,  and  AD18),  and  Sensor  Position  Vector  (AD25,  AD26, 
and  AD27).  They  are  sent  only  when  the  platform  provides  these  parameters. 


Table  B-3.  Reference  Coordinate  Systems 


COORDINATE  SYSTEM 

VALUE 

Unidentified 

0 

GEI:  Geocentric  Equatorial  Inertial,  also  known  as  True  Equator  and  Tme  Equinox 
of  Date,  True  of  Date  (TOD),  ECI,  or  GCI 

1 

J2000:  Geocentric  Equatorial  Inertial  for  epoch  J2000.0  (GEI2000),  also  known  as 
Mean  Equator  and  Mean  Equinox  of  J2000.0 

2 

GEO:  Geographic,  also  known  as  Greenwich  Rotating  Coordinates  (GRC),  or 
Earth-fixed  Greenwich  (EFG) 

3 

Available  for  Future  Use 

4-255 

B.1.6  Slant  Range  Sample  Spacing  (AD6)  (O). 

Slant  range  pixel  spacing  after  over  sampling,  expressed  in  centimetres. 
Field  AD6  is  Optional 
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B.1.7  Cross  Range  Sample  Spacing  (AD7)  (O). 

Cross  range  pixel  spacing  after  over  sampling,  expressed  in  centimetres. 
Field  AD7  is  Optional. 

B.1.8  Slant  Range  Resolution  (AD8)  (O). 

The  3dB  range  impulse  response  of  the  radar,  expressed  in  centimetres. 

Field  AD9  is  Optional 

B.1.9  Cross  Range  Resolution  (AD9)  (O). 

The  3dB  cross  range  impulse  response  of  the  radar,  expressed  in  centimetres. 
Field  AD9  is  Optional 


B.I.IOPIatform  Position  -  X  Coordinate  (AD10)  (C). 


The  coordinate  of  the  platform  position  in  the  X  direction  of  the  reference  coordinate  system 
defined  in  field  AD5,  expressed  in  millimetres. 

Field  AD  10  is  Conditional  and  is  always  sent  with  Reference  Coordinate  System  (AD5)  and 
fields  ADI  1  and  AD12.  They  are  sent  only  when  the  platform  provides  these  parameters. 


B.1 .11  Platform  Position  -  Y  Coordinate  (AD11)  (C). 


The  coordinate  of  the  platform  position  in  the  Y  direction  of  the  reference  coordinate  system 
defined  in  field  AD5,  expressed  in  millimetres. 

Field  AD  1 1  is  Conditional  and  is  always  sent  with  Reference  Coordinate  System  (AD5)  and 
fields  AD10  and  AD12.  They  are  sent  only  when  the  platform  provides  these  parameters. 


B.1 .12 Platform  Position  -Z  Coordinate  (AD12)  (C). 


The  coordinate  of  the  platform  position  in  the  Z  direction  of  the  reference  coordinate  system 
defined  in  field  AD5,  expressed  in  millimetres. 

Field  AD  12  is  Conditional  and  is  always  sent  with  Reference  Coordinate  System  (AD5)  and 
fields  AD  10  and  ADI  1.  They  are  sent  only  when  the  platform  provides  these  parameters. 
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B.1.13Platform  Position  Uncertainty -X  Coordinate  (AD13)  (O). 


Estimate  of  the  standard  deviation  in  the  platform  position  at  the  time  of  the  dwell,  measured  in 
the  X  direction  of  the  reference  coordinate  system  defined  in  field  AD  5,  expressed  in  millimetres. 

Field  AD13  is  Optional.  It  is  always  sent  with  fields  AD5,  AD14,  and  AD15. 


B.1.14Platform  Position  Uncertainty -Y  Coordinate  (AD14)  (O). 


Estimate  of  the  standard  deviation  in  the  platform  position  at  the  time  of  the  dwell,  measured  in 
the  Y  direction  of  the  reference  coordinate  system  defined  in  field  ADS,  expressed  in  millimetres. 

Field  AD14  is  Optional.  It  is  always  sent  with  fields  AD5,  AD13,  and  AD15. 


B.1.15Platform  Position  Uncertainty  -  Z  Coordinate  (ADI  5)  (O). 


Estimate  of  the  standard  deviation  in  the  platform  position  at  the  time  of  the  dwell,  measured  in 
the  Z  direction  of  the  reference  coordinate  system  defined  in  field  AD5,  expressed  in  millimetres. 

Field  AD15  is  Optional.  It  is  always  sent  with  fields  AD5,  AD13,  and  AD14 


B.1.16Platform  Velocity -X-  Prime  (ADI 6)  (C). 


The  velocity  of  the  platform  in  the  X  direction  of  the  reference  coordinate  system  defined  in  field 
AD5,  expressed  as  millimetres  per  second,  at  the  time  of  the  dwell. 

Field  AD  16  is  Conditional  and  is  always  sent  with  fields  AD5,  AD  17,  and  AD  18.  They  are  sent 
only  when  the  sensor  system  provides  these  parameters. 


B.1.17Platform  Velocity  -  Y-  Prime  (AD17)  (C). 


The  velocity  of  the  platform  in  the  Y  direction  of  the  reference  coordinate  system  defined  in  field 
AD5,  expressed  as  millimetres  per  second,  at  the  time  of  the  dwell. 

Field  AD  17  is  Conditional  and  is  always  sent  with  fields  AD5,  AD  16,  and  AD  18.  They  are  sent 
only  when  the  sensor  system  provides  these  parameters. 


B.1.18Platform  Velocity  -  Z-  Prime  (AD18)  (C). 


The  velocity  of  the  platform  in  the  Z  direction  of  the  reference  coordinate  system  defined  in  field 
AD5,  expressed  as  millimetres  per  second,  at  the  time  of  the  dwell. 
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Field  AD  18  is  Conditional  and  is  always  sent  with  fields  AD5,  AD  16,  and  AD  17.  They  are  sent 
only  when  the  sensor  system  provides  these  parameters. 


B.1.19Platform  Velocity  Uncertainty  -  X-Prime  (AD19)  (O). 


The  standard  deviation  of  the  estimate  of  the  platform  velocity  in  the  X  direction  of  the  reference 
coordinate  system  defined  in  field  AD5,  expressed  as  millimetres  per  second. 

Field  AD  19  is  Optional.  It  is  always  sent  with  fields  AD5,  AD20,  and  AD21. 


B.1.20Platform  Velocity  Uncertainty  -  Y-Prime  (AD20)  (O). 


The  standard  deviation  of  the  estimate  of  the  platform  velocity  in  the  Y  direction  of  the  reference 
coordinate  system  defined  in  field  AD5,  expressed  as  millimetres  per  second. 

Field  AD20  is  Optional.  It  is  always  sent  with  fields  AD5,  AD  19,  and  AD21. 


B.1.21  Platform  Velocity  Uncertainty  -  Z-Prime  (AD21)  (O). 


The  standard  deviation  of  the  estimate  of  the  platform  velocity  in  the  Z  direction  of  the  reference 
coordinate  system  defined  in  field  AD5,  expressed  as  millimetres  per  second. 

Field  AD21  is  Optional.  It  is  always  sent  with  fields  AD5,  AD  19,  and  AD20. 


B.1.22High  Resolution  Platform  Orientation  -  Yaw  (AD22)  (C). 


The  rotation  angle  of  the  platform  about  the  platform  yaw  axis  at  the  time  of  the  dwell  expressed 
in  degrees,  from  the  Sensor  Velocity  vector  defined  in  fields  AD16-AD18  to  the  platform  roll  axis, 
where  platform  yaw  axis  and  platform  roll  axis  are  defined  in  Figure  B-l. 

A  positive  platform  yaw  angle  is  in  a  clockwise  direction  when  viewed  from  above.  The  High 
Resolution  Platform  Orientation  describes  the  coordinate  systems  used  for  spacebome  platforms 
and  provides  increased  resolution  compared  to  the  Platform  Orientation  field  provided  in  the 
baseline  (airborne)  dwell  segment.  Refer  to  figure  A- 1  in  Annex  A  for  the  description  of 
coordinate  systems  for  airborne  platforms. 

Field  AD22  is  Conditional  and  is  always  sent  with  fields  AD23  and  AD24.  They  are  sent  only 
when  the  platform  provides  these  parameters. 
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Figure  B-l.  Platform  Orientation  Axes  (from  [5]) 
(order  of  rotation:  Yaw,  then  Pitch,  then  Roll.) 


B.1.23High  Resolution  Platform  Orientation  -  Pitch  (AD23)  (C). 


The  rotation  angle  of  the  platform  about  the  platform  pitch  axis  at  the  time  of  the  dwell,  as 
defined  in  Figure  B-l,  expressed  in  degrees.  A  positive  pitch  angle  is  a  rotation  about  the 
Platform  Pitch  Axis,  bringing  the  Platform  Yaw  Axis  in  the  direction  of  the  Sensor  Velocity  vector 
defined  in  fields  AD  16- AD  18. 

Field  AD23  is  Conditional  and  is  always  sent  with  fields  AD22  and  AD24.  They  are  sent  only 
when  the  platform  provides  these  parameters. 
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B.1.24High  Resolution  Platform  Orientation  -  Roll  (AD24)  (C). 


The  rotation  angle  of  the  platform  about  the  platform  roll  axis  at  the  time  of  the  dwell,  as  defined 
in  Figure  B-l,  expressed  in  degrees.  A  positive  platform  roll  angle  is  the  clockwise  direction  as 
viewed  in  the  general  direction  of  the  Platform  Velocity  vector  defined  in  fields  AD  16-AD  18. 

Field  AD24  is  Conditional  and  is  always  sent  with  fields  AD22  and  AD23.  They  are  sent  only 
when  the  platform  provides  these  parameters. 


B.1.25Sensor  Position  Vector -X  Coordinate  (AD25)  (O). 


The  vector  from  the  Platform  Position  (platform  centre  of  gravity)  to  the  Sensor  Position  (phase 
centre  of  the  sensor)  in  the  X  direction  of  the  reference  coordinate  system  defined  in  field  AD5, 
expressed  in  millimetres. 

Field  AD25  is  Optional.  It  is  always  sent  with  fields  AD26  and  AD27. 


B.1.26Sensor  Position  Vector- Y  Coordinate  (AD26)  (O). 


The  vector  from  the  Platform  Position  (platform  centre  of  gravity)  to  the  Sensor  Position  (phase 
centre  of  the  sensor)  in  the  X  direction  of  the  reference  coordinate  system  defined  in  field  AD5, 
expressed  in  millimetres. 

Field  AD26  is  Optional.  It  is  always  sent  with  fields  AD25  and  AD27. 


B.1 .27 Sensor  Position  Vector -Z  Coordinate  (AD27)  (O). 


The  vector  from  the  Platform  Position  (platform  centre  of  gravity)  to  the  Sensor  Position  (phase 
centre  of  the  sensor)  in  the  X  direction  of  the  reference  coordinate  system  defined  in  field  AD5, 
expressed  in  millimetres. 

Field  AD27  is  Optional.  It  is  always  sent  with  fields  AD25  and  AD26. 


B.1.28Hiqh  Resolution  Sensor  Orientation  -  Yaw  (AD28)  (O). 


High  Resolution  Sensor  Orientation  describes  the  pointing  attitude  of  the  sensor  in  terms  of  Yaw, 
Pitch,  and  Roll.  These  values  refer  to  the  successive  rotations  from  a  nominal  sensor  “rest” 
position,  and  result  in  a  pointing  vector  that  coincides  with  the  radar  “beam  ’’from  the  sensor. 
This  pointing  vector  describes  the  orientation  of  the  radar  beam,  and  is  independent  of  any 
mechanical  articulation  used  to  point  the  beam.  (Refer  to  AEDP-7,  Annex  E for  additional 
information.)  High  Resolution  Sensor  Orientation  provides  increases  resolution  compared  to  the 
Sensor  Orientation  field  provided  in  the  baseline  dwell  segment. 
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High  Resolution  Sensor  Orientation  -  Yaw  describes  the  rotation  of  the  sensor/beam  about  the 
sensor  yaw  axis,  as  defined  in  Figure  B-l,  expressed  in  degrees  clockwise  when  viewed  from 
above. 

This  is  the  first  of  three  successive  rotations  from  a  hypothetical  initial  position  in  which  the 
sensor  broadside  (normal  to  the  sensor  face)  is  in  its  nominal  “rest”  position.  For  downward¬ 
looking  space-based  sensors,  the  “rest”  position  will  be  with  the  sensor/beam  facing  towards 
nadir  and  the  principal  axis  of  the  sensor  will  be  parallel  to  the  platform  roll  axis.  When  in  the 
“rest”  position,  the  sensor  roll,  pitch,  and  yaw  axes  are  parallel  to  the  platform  roll,  pitch,  and  yaw 
axes,  respectively.  For  a  “body  mounted”  sensor,  whether  an  electronically  scanned  array  (ESA) 
or  a  reflector,  the  Fligh  Resolution  Sensor  Orientation  fields  (AD28,  AD29,  AD30)  refer  to  the 
orientation  of  the  sensor  field  of  view,  or  “beam”.  For  an  “articulated”  sensor,  the  Fligh 
Resolution  Sensor  Orientation  fields  (  AD28,  AD29,  AD30)  refer  to  the  orientation  of  the  sensor 
field  of  view,  or  “beam”,  and  are  independent  of  the  physical  orientation  of  the  sensor  face. 

Field  AD28  is  Optional.  If  at  least  one  of  fields  AD28,  AD29,  or  AD30  is  present,  then  any 
omitted  field  shall  represent  an  angle  of  zero  degrees. 


B.1.29High  Resolution  Sensor  Orientation  -  Pitch  (AD29)  (O). 


The  rotation  angle  of  the  sensor/beam  about  the  sensor  pitch  axis  at  the  time  of  the  dwell,  as 
defined  in  Figure  B-l,  expressed  in  degrees. 

As  viewed  from  the  “rest”  position,  a  positive  pitch  angle  is  a  rotation  about  the  Sensor  Pitch 
Axis,  bringing  the  Sensor  Yaw  Axis  in  the  direction  of  the  Sensor  Velocity  vector  defined  in 
fields  AD16-AD18.  This  is  the  second  of  three  successive  rotations  from  the  hypothetical  initial 
position  of  the  sensor,  as  described  above. 

Field  AD29  is  Optional.  If  at  least  one  of  fields  AD28,  AD29,  or  AD30  is  present,  then  any 
omitted  field  shall  represent  an  angle  of  zero  degrees. 


B.1.30High  Resolution  Sensor  Orientation  -  Roll  (AD30)  (O). 


The  rotation  angle  of  the  sensor/beam  about  the  sensor  roll  axis  at  the  time  of  the  dwell  as 
defined  in  Figure  B-l,  expressed  in  degrees. 

A  positive  roll  angle  is  the  clockwise  direction  as  viewed  in  the  general  direction  of  the  Sensor 
Velocity  vector  defined  in  fields  AD  16-AD  18.  This  is  the  third  of  three  successive  rotations  from 
the  hypothetical  initial  position  of  the  sensor,  as  described  above. 

Field  AD30  is  Optional.  If  at  least  one  of  fields  AD28,  AD29,  or  AD30  is  present,  then  any 
omitted  field  shall  represent  an  angle  of  zero  degrees. 
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B.1 .31  Dwell  Area  Centre  Elevation  (AD31)  (O) 

Dwell  Area  Centre  Elevation,  expressed  in  metres. 

This  information  supplements  Dwell  Area  Centre  Latitude  (D24)  and  Dwell  Area  Centre 
Longitude  (D25)  in  the  STANAG  4607  Dwell  Segment.  Field  AD31  is  Optional. 

B.1.32<  Advanced  Target  Report  Extensions  >. 

Table  B-4  describes  the  format  for  the  Advanced  Target  Report  Extensions.  One  Target  Report 
Extension  shall  be  transmitted  for  each  target  observed  within  the  dwell.  Targets  detected  within  a 
dwell  may  be  split  among  multiple  Advanced  Dwell  Segment  Extensions.  Targets  detected  within 
a  dwell  but  detected  by  different  radar  modes  or  radar  processors  shall  be  reported  in  separate 
Advanced  Dwell  Segments 
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Table  B-4.  Advanced  Target  Report  Extension 


Field 

Type 

Field  Name 

Bytes 

Form 

Value  Range 

Units 

AD32.1 

M 

MTI  Report  Index 

2 

116 

0  to  65535 

none 

AD32.2 

O 

Target  Slant  Range 

4 

132 

0  to  4294967296 

centimetres 

AD32.3 

O 

Target  Slow  Time 

2 

S32 

-21474836548  to 
+21474836547 

Ten 

Nanoseconds 

AD32.4 

o 

Target  Sine  Left  Angle 

4 

S32 

-2147483648  to 
+2147483647 

1/2147483648 

AD32.5 

o 

Target  Sine  Up  Angle 

4 

S32 

-21474836548  to 
+21474836547 

1/2147483648 

AD32.6 

o 

Target  Velocity 

Ground  Range  Component 

2 

S16 

-32768  to  +32767,  where  + 
means  increasing  range 
away  from  the  sensor 

centimetres/sec 

AD32.7 

o 

Target  Velocity 

Cross  Range  Component 

2 

S16 

-32768  to  +32767,  where  + 
is  in  the  direction  of 
platform  motion 

centimetres/sec 

AD32.8 

o 

Target  Ground  Speed 

2 

116 

0  to  65535 

centimetres/sec 

AD32.9 

o 

Target  Heading 

4 

BA32 

0  to  +359.999979 

degrees 

AD32.10 

o 

Target  Wrap  Range 

4 

132 

0  to  4294967295 

centimetres 

AD32.11 

o 

Target  RCS 

2 

S16 

-32768  to  +32767 

1/100  dBsm 

AD32.12 

o 

Target  Incidence  Angle 

2 

SA16 

0  to  +89.999999958 

degrees 

AD32.13 

c 

Target 

Measurement 
Uncertainty 
(one  standard 
deviation) 

Target  Sine 
Left  Angle 

2 

116 

0  to  32767 

1/32767 

AD32.14 

c 

Target  Sine 
Up  Angle 

2 

116 

0  to  32767 

1/32767 

AD32.15 

c 

Target 

Velocity 

Ground 

Range 

Component 

2 

116 

0  to  65535 

millimetres/sec 

AD32.16 

c 

Target 
Velocity 
Cross  Range 
Component 

2 

116 

0  to  65535 

milliimetres/sec 

AD32.17 

c 

Target 

Ground 

Speed 

2 

116 

0  to  65535 

millimetres/sec 

AD32.18 

c 

Target 

Heading 

2 

SA16 

0  to  +89.999999958 

degrees 

B. 1.32.1  MTI  Report  Index  (AD32.1)  (M). 

The  sequential  count  of  this  MTI  report  within  the  dwell. 
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The  MTI  Report  Index  provides  linkage  between  target  reports  in  the  Advanced  Dwell  Segment 
Extension  and  target  reports  in  the  baseline  Dwell  Segment,  and  must  be  the  same  as  the  MTI 
Report  Index  of  target  reports  in  the  baseline  Dwell  Segment. 


B.  1.32. 2  Target  Slant  Range  (AD32.2)  (O). 

Measured  slant  range  in  centimetres  from  the  sensor  to  the  target. 

This  field  is  optional.  If  Target  Slant  Range  is  sent,  then  its  uncertainty  (field  D32.12  in  the 
baseline  Target  Report)  must  also  be  sent. 


B. 1.32. 3  Target  Slow  Time  (AD32.3)  (O). 

The  time  at  which  the  centre  of  the  main  beam  crosses  the  target,  expressed  as  an  offset  in  tens  of 
nanoseconds  from  the  dwell  time. 

For  a  sensor  looking  broadside  at  a  flat  earth  or  non-rotating  ellipsoidal  earth,  this  is  the  time  at 
which  the  Doppler  shift  between  the  target  and  the  platform  is  zero  (i.e.  the  point  of  closest 
approach  of  the  platform  to  the  target).  See  Appendix  E  in  the  AEDP-7  for  more  information. 

This  field  is  Optional. 


B. 1.32. 4  Target  Sine  Left  Angle  (AD32.4)  (O). 

Measured  target  angle  leftward  from  the  look  vector  defined  by  the  sensor  position  (Fields  AD25 
to  AD27)  and  orientation  (Fields  AD28  to  AD30). 

Let  x,  y,  and  z  be  a  Cartesian  coordinate  system  centred  on  the  antenna,  such  that  the  z  axis  is  in 
the  direction  of  the  sensor  look  vector.  The  x  axis  is  normal  to  the  look  vector,  in  the  scan 
direction  closest  to  horizontal,  oriented  leftward  when  looking  outward  from  the  antenna.  The  y 
axis  is  the  cross  product  of  the  z  and  x  axes.  Then  for  target  coordinates  x,  y,  z,  the  target  sine 
left  angle  is: 


x 

u  =  , 

/  2  .  2  .  2 

v*  +y  +z 

This  value  is  unitless,  and  is  expressed  with  a  precision  of  1/231.  Thus,  the  integer  1859775394 
represents  a  target  left  angle  of  60  degrees,  since 


sin 


V3 

2 


1859775394 

231 


1859775394 

2147483648 


Target  sine  left  angle  should  be  sent  for  an  electronically  scanned  antenna  where  the  angle 
measurement  uncertainty  is  best  described  in  sine  space. 
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This  field  is  optional.  If  Target  Sine  Left  Angle  is  sent,  then  its  uncertainty  (field  AD32.12) 
should  also  be  sent,  but  the  Target  Cross  Range  Uncertainty  (D32.13  in  the  baseline  Target 
Report)  need  not  be  sent. 


B.  1.32. 5  Target  Sine  Up  Angle:  (AD32.5)  (O). 

Measured  target  angle  leftward  from  the  look  vector  defined  by  the  sensor  position  (Fields  AD25 
to  AD27)  and  orientation  (Fields  AD 2 8  to  AD30). 

Let  x,  y,  and  z  be  a  Cartesian  coordinate  system  centred  on  the  antenna,  such  that  the  z  axis  is  in 
the  direction  of  the  sensor  look  vector.  The  x  axis  is  normal  to  the  look  vector,  in  the  scan 
direction  closest  to  horizontal,  oriented  leftward  when  looking  outward  from  the  antenna.  The  y 
axis  is  the  cross  product  of  the  z  and  x  axes.  Then  for  target  coordinates  x,  y,  z,  the  target  sine  up 
angle  is: 


+  y~  +  z 

Target  sine  up  angle  should  be  sent  for  an  electronically  scanned  antenna  where  the  angle 
measurement  uncertainty  is  best  described  in  sine  space. 

This  field  is  optional.  If  Target  Sine  Up  Angle  is  sent,  then  its  uncertainty  (  AD32. 14)  should  also 
be  sent,  but  the  Target  Cross  Range  Uncertainty  (D32.13  in  the  baseline  Target  Report)  need  not 
be  sent. 


B.  1.32. 6  Target  Velocity  Ground  Range  Component  (AD32.6)  (O). 

The  component  of  the  ground  velocity  for  the  reported  detection,  in  the  range  direction,  corrected 
for  platform  motion.  It  is  reported  in  centimetres  per  second  and  the  positive  direction  is  away 
from  the  sensor. 

Note  that  this  is  simply  the  target  radial  velocity  component  (D32.7  in  the  baseline  Target  Report) 
projected  onto  the  ground.  This  field  is  Optional.  If  Target  Velocity  Ground  Range  Component  is 
sent,  then  its  uncertainty  (AD32.15)  should  also  be  sent. 


B. 1.32. 7  Target  Velocity  Cross-Range  Component  (AD32.7)  (O). 

The  component  of  the  ground  velocity  for  the  reported  detection,  in  the  cross-range  direction, 
corrected  for  platform  motion.  For  a  side  looking  sensor,  the  cross-range  direction  is  along  the 
sensor  track.  It  is  reported  in  centimetres  per  second  and  the  positive  direction  is  in  the  direction 
of  the  platform  motion. 

This  field  is  Optional.  If  Target  Velocity  Cross-Range  Component  is  sent,  then  its  uncertainty 
(AD32.16)  should  also  be  sent. 


62 


DRDC  Ottawa  TM  2007-341 


B. 1.32. 8 


Target  Ground  Speed  (AD32.8)  (O). 


The  ground  speed  of  the  target,  reported  in  centimetres  per  second. 

This  field  is  Optional.  If  Target  Ground  Speed  is  sent,  then  its  uncertainty  (AD32.17)  should  also 
be  sent. 


B. 1.32. 9  Target  Heading  (AD32.9)  (O). 

The  true  heading  of  the  target,  reported  in  degrees  from  true  north  measured  in  the 
counterclockwise  direction. 

This  field  is  Optional.  If  Target  Heading  is  sent,  then  its  uncertainty  (AD32.18)  should  also  be 
sent. 


B. 1.32. 10  Target  Wrap  Range  (AD32.10)  (O). 

The  range  aliasing  distance. 

The  target  wrap  range  permits  MTI  trackers  to  un-wrap  aliased  measured  slant  ranges.  When  the 
target’s  wrap  range  is  small  compared  to  the  expected  slant  range,  the  tracker  may  consider 
adding  multiples  of  the  wrap  range  to  the  measured  slant  range  (AD32.2).  It  should  be  sent  if  the 
wrap  range  is  smaller  than  plausible  target  slant  ranges  (e.g.  if  there  were  too  many  missed 
detections  to  resolve  the  range  ambiguity). 

This  field  is  Optional.  If  it  is  sent,  then  the  target  slant  range  (AD32.2)  shall  also  be  sent. 


B. 1.32. 11  Target  Radar  Cross  Section  (AD32.11)  (O). 


The  target  radar  cross  section  in  hundredths  of  a  dB,  relative  to  a  square  metre  (dBsm). 

/ 

RCS(dBsm)  =  10  log 


rRCS(m 2)A 


1  m 

v  / 

The  integer  range  of  values  can  accommodate  RCS  from  -327.68  to  327.67  dBsm. 
This  field  is  Optional 


B.  1.32. 12  Target  Incidence  Angle  (AD32.12)  (O). 

The  incidence  angle  at  the  target,  reported  in  degrees. 

This  is  the  angle  between  the  normal  to  the  WGS  ellipsoid  at  the  target  location  and  the  slant 
range  (or  sensor-target  line  of  sight)  vector.  In  a  flat  earth  model  (i.e.  if  field  J28  is  set  to  3),  the 
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incidence  angle  is  equal  to  the  elevation  angle  (The  angle  between  the  slant  range  and  nadir 
vectors).  This  field  is  Optional. 


B. 1.32. 13  Target  Measurement  Uncertainty  -  Target  Sine  Left  Angle  (AD32.13) 

(Oli 

The  one  sigma  uncertainty  in  the  Target  Sine  Left  Angle. 

This  field  is  optional.  If  it  is  sent,  then  the  target  sine  left  angle  (AD32.4)  shall  also  be  sent. 

B. 1.32. 14  Target  Measurement  Uncertainty  -  Target  Sine  Up  Angle  (AD32.14) 

(Oil 

The  one  sigma  uncertainty  in  the  Target  Sine  Up  Angle. 

This  field  is  optional.  If  it  is  sent,  then  the  target  sine  left  angle  (AD32.5)  shall  also  be  sent. 


B.  1.32. 15  Target  Measurement  Uncertainty  -  Target  Velocity  Ground  Range 
Component  (AD32.15)  (O). 

The  standard  deviation  of  the  Target  Velocity  Ground  Range  Component  reported  in  field 
AD32.6,  expressed  in  millimetres  per  second. 

This  field  is  Optional. 


B. 1.32. 16  Target  Measurement  Uncertainty  -  Target  Velocity  Cross  Range 

Component  (AD32.16)  (O). 

The  standard  deviation  of  the  Target  Velocity  Cross  Range  Component  reported  in  field  AD32. 7, 
expressed  in  millimetres  per  second. 

This  field  is  Optional. 


B.  1.32. 17  Target  Measurement  Uncertainty  -  Target  Ground  Speed  (AD32.17) 

(OL 

The  standard  deviation  of  the  Target  Ground  Speed  reported  in  field  AD32. 8,  expressed  in 
millimetres  per  second. 

This  field  is  Optional. 
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B.  1.32. 18  Target  Measurement  Uncertainty  -  Target  Heading  (AD32.18)  (O). 


The  standard  deviation  of  the  Target  Heading  reported  in  field  AD32. 9,  expressed  in  degrees. 
This  field  is  Optional. 

B.2  Advanced  Job  Definition  Extension 


The  Advanced  Job  Definition  Extension  (Table  B-5)  provides  the  means  for  the  platform  to  pass 
information  pertaining  to  the  sensor  job  that  will  be  performed  and  details  of  the  location 
parameters  (terrain  elevation  model  and  geoid  model)  used  in  the  measurement.  It  includes  a 
definition  of  the  geographic  area  for  sensor  service,  which  is  defined  as  a  four-comer  polygon, 
with  the  four  points  of  the  polygon  chosen  to  define  a  convex  quadrilateral.  The  Advanced  Job 
Definition  Extension  shall  be  sent  in  conjunction  with  the  parent  Job  Definition  Segment  when 
Advanced  extensions  are  sent.  Note  that  precision  location  of  a  target  will  not  be  possible  until 
the  information  contained  in  the  Advanced  Job  Definition  Extension  has  been  received  from  the 
transmitting  platform.  The  Advanced  Job  Definition  Extension  supplements  the  Job  Definition 
Segment  described  in  Annex  A  of  this  document. 
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Table  B-5.  Advanced  Job  Definition  Extension 


Field 

Type 

Field  Name 

Bytes 

Form 

Value  Range 

Units 

AJ1 

M 

Job  ID 

4 

132 

0  to  4294967295 

AJ2 

M 

Radar  Carrier  Frequency 

4 

132 

0  to  4294967000, 
4294967295+No 
Statement 

kiloHertz 

AJ3 

M 

Azimuth  3  dB  Beamwidth 

4 

BA32 

0  to +179.999979, 
180.0  =  No  Statement 

degrees 

AJ4 

M 

Elevation  3dB  Beamwidth 

4 

BA32 

0  to +179.999979, 
180.0  =  No  Statement 

degrees 

AJ5 

M 

Nominal 

Platform 

Position 

Uncertainty 

X 

4 

132 

0  to  4294967000, 
4294967295+No 
Statement 

millimetres 

AJ6 

M 

Y 

4 

132 

0  to  4294967000, 
4294967295+No 
Statement 

millimetres 

AJ7 

M 

Z 

4 

132 

0  to  4294967000, 
4294967295+No 
Statement 

millimetres 

AJ8 

M 

Nominal 

Platform 

Velocity 

Uncertainty 

X-Prime 

2 

116 

0  to  65535 

millimetres/sec 

AJ9 

M 

Y -  Prime 

2 

116 

0  to  65535 

millimetres/sec 

AJ10 

M 

Z-  Prime 

2 

116 

0  to  65535 

millimetres/sec 

B.2.1  Job  ID  (AJ1)  (M). 


A  platform  assigned  number  identifying  the  specific  request  or  task  to  which  the  dwell  pertains. 

This  value  must  be  the  same  as  the  Job  ID  in  the  Job  Definition  Segment  in  Para.  2.7  of  Part  2  of 
Annex  A  to  STANAG  4607. 

B.2.2  Radar  Carrier  Frequency  (AJ2)  (M). 

The  radar’s  centre  (carrier)  frequency,  reported  in  kiloHertz  (kHz). 

This  field  is  mandatory.  The  No-Statement  value  is  sent  when  the  sensor  is  unable  or  unwilling  to 
provide  a  value. 

B.2.3  Azimuth  3dB  Beamwidth  (AJ3)  (M). 

The  3dB  width  of  the  main  beam ,  in  the  Azimuth  (Scan)  direction,  reported  in  degrees. 

The  No-Statement  value  is  sent  when  the  Azimuth  3dB  Beamwidth  is  not  provided. 
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B.2.4  Elevation  3dB  Beamwidth  (AJ4)  (M). 

The  3dB  width  of  the  main  beam,  in  the  elevation  direction,  reported  in  degrees. 

The  No-Statement  value  is  sent  when  the  Elevation  3dB  Beamwidth  is  not  provided. 

B.2.5  Nominal  Platform  Position  Uncertainty  -  X  Coordinate  (AJ5)  (M). 


Nominal  estimate  of  the  standard  deviation  in  the  platform  position,  measured  in  the  X  direction 
of  the  reference  coordinate  system  defined  in  field  AD5,  expressed  in  millimetres. 

The  No-Statement  value  is  sent  when  the  sensor  is  unable  or  unwilling  to  provide  a  value. 

(NOTE:  The  Nominal  fields  in  the  Advanced  Job  Definition  Extension  provide  a  means  for 
reporting  nominal  standard  deviations  and  uncertainty  values,  and  are  to  be  used  when  values  are 
not  received  from  the  sensor.  More  precise  values  of  these  or  related  estimates  may  be  reported  in 
the  appropriate  fields  in  either  the  Advanced  Dwell  Segment  Extension  or  the  Target  Report  Sub- 
Segment,  when  the  sensor  computes  them  and  the  communication  bandwidth  permits  the  more 
frequent  reporting.) 


B.2.6  Nominal  Platform  Position  Uncertainty  -  Y  Coordinate  (AJ6)  (M). 


Nominal  estimate  of  the  standard  deviation  in  the  platform  position,  measured  in  the  Y  direction 
of  the  reference  coordinate  system  defined  in  field  AD5,  expressed  in  millimetres. 

The  No-Statement  value  is  sent  when  the  sensor  is  unable  or  unwilling  to  provide  a  value. 


B.2.7  Nominal  Platform  Position  Uncertainty  -  Z  Coordinate  (AJ7)  (M). 


Nominal  estimate  of  the  standard  deviation  in  the  platform  position,  measured  in  the  Z  direction 
of  the  reference  coordinate  system  defined  in  field  AD5,  expressed  in  millimetres. 

The  No-Statement  value  is  sent  when  the  sensor  is  unable  or  unwilling  to  provide  a  value. 


B.2.8  Nominal  Platform  Velocity  Uncertainty  -  X-Prime  (AJ8)  (M). 


The  standard  deviation  of  the  estimate  of  the  platform  velocity  in  the  X  direction  of  the  reference 
coordinate  system  defined  in  field  AD5,  expressed  as  millimetres  per  second. 


B.2.9  Nominal  Platform  Velocity  Uncertainty  -  Y-Prime  (AJ9)  (M). 


The  standard  deviation  of  the  estimate  of  the  platform  velocity  in  the  Y  direction  of  the  reference 
coordinate  system  defined  in  field  AD5,  expressed  as  millimetres  per  second. 
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B.2.10Nominal  Platform  Velocity  Uncertainty  -  Z-Prime  (AJ10)  (M). 


The  standard  deviation  of  the  estimate  of  the  platform  velocity  in  the  Z  direction  of  the  reference 
coordinate  system  defined  in  field  AD5,  expressed  as  millimetres  per  second. 


B.3  Advanced  Platform  Location  Segment 


The  Advanced  Platform  Location  Extension  (Table  B-6)  provides  information  pertaining  to  the 
location  of  the  sensor  platform  during  periods  when  the  sensor  is  not  collecting  data.  It  shall  be 
sent  as  required  during  periods  in  which  the  sensor  is  not  collecting  data,  such  as  sensor  idle 
times,  enroute  to  an  orbital  location,  or  during  a  slewing  operation.  The  Advanced  Platform 
Location  Extension  supplements  the  Platform  Location  Segment  Annex  A  of  this  document. 


Table  B-6.  Advanced  Platform  Location  Extension 


Field 

Type 

Field  Name 

Bytes 

Form 

Value  Range 

units 

API 

M 

Location  Time 

4 

132 

0  to  4  x  (109) 

milliseconds 

AP2 

M 

Reference  Coordinate 

System 

1 

E8 

Per  para.  4.3.2 

AP3 

M 

Platform 

Position 

X 

4 

S64 

(-26J)  to  (26J  -  1 ) 

millimetres 

AP4 

M 

Y 

4 

S64 

(-26J)  to  (2“-l) 

millimetres 

AP5 

M 

Z 

4 

S64 

(-263)  to  (2W  —  1) 

millimetres 

AP6 

M 

Platform 

Velocity 

X-Prime 

4 

S32 

-2147483648  to 
2147483647 

millimetres/sec 

AP7 

M 

Y -Prime 

4 

S32 

-2147483648  to 
2147483647 

millimetres/sec 

AP8 

M 

Z-Prime 

4 

S32 

-2147483648  to 
2147483647 

millimetres/sec 

B.3.1  Location  Time  (API)  (M). 

The  elapsed  time ,  expressed  in  milliseconds,  from  midnight  at  the  beginning  of  the  day  specified 
in  the  Reference  Time  fields  of  the  Mission  Segment  to  the  time  the  report  is  prepared. 

In  this  manner,  the  Location  Time  corresponds  to  the  day's  UTC  time  converted  to  milliseconds, 
with  the  possible  addition  of  multiples  of  86400000  for  multi-day  missions. 
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B.3.2  Reference  Coordinate  System  (AP2)  (M). 


An  enumeration  table  that  identifies  the  reference  coordinate  system  for  the  platform. 
Coordinate  systems  are  listed  in  Table  B-3. 


B.3.3  Platform  Position  -X  Coordinate  (AP3)  (M). 


The  coordinate  of  the  sensor  platform  in  the  X  direction  of  the  reference  coordinate  system 
defined  in  field  AP2,  expressed  in  millimetres,  at  the  Location  Time  provided  in  field  API. 


B.3.4  Platform  Position  -  Y  Coordinate  (AP4)  (M). 


The  coordinate  of  the  sensor  platform  in  the  Y  direction  of  the  reference  coordinate  system 
defined  in  field  AP2,  expressed  in  millimetres,  at  the  Location  Time  provided  in  field  API. 


B.3.5  Platform  Position  -  Z  Coordinate  (AP5)  (M). 


The  coordinate  of  the  sensor  platform  in  the  Z  direction  of  the  reference  coordinate  system 
defined  in  field  AP2,  expressed  in  millimetres,  at  the  Location  Time  provided  in  field  API. 


B.3.6  Platform  Velocity  -  X-  Prime  (AP6)  (M). 


The  velocity  of  the  sensor  in  the  X  direction  of  the  reference  coordinate  system  defined  in  field 
AP2,  expressed  as  millimetres  per  second,  at  the  Location  Time  provided  in  field  API. 


B.3.7  Platform  Velocity  -  Y-  Prime  (AP7)  (M). 


The  velocity  of  the  sensor  in  the  Y  direction  of  the  reference  coordinate  system  defined  in  field 
AP2,  expressed  as  millimetres  per  second,  at  the  Location  Time  provided  in  field  API. 


B.3.8  Platform  Velocity  -  Z-  Prime  (AP8)  (M). 


The  velocity  of  the  sensor  in  the  Z  direction  of  the  reference  coordinate  system  defined  in  field 
AP2,  expressed  as  millimetres  per  second,  at  the  Location  Time  provided  in  field  API. 
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